[closer-devel] using a custom unbound slot marker

[Pascal Costanza]

On 1 Nov 2006, at 11:11, Attila Lendvai wrote:

> One trick I have used once is to just inspect the unbound value  
> that is used by the CLOS implementation. You can do this in a  
> portable way, like this:
>
> (defclass test ()
>   (test-slot))
>
> (defvar +unbound-slot-value+
>   (let ((test (make-instance 'test)))
>     (standard-instance-access test
>       (slot-definition-location
>         (find 'test-slot (class-slots (find-class 'test))
>               :key #'slot-definition-name)))))
>
> (setf (find-class 'test) nil)
>
> This code assumes that the value for unbound slots remains constant  
> for the lifetime of an image (but I can't imagine why that would  
> not be the case).
>
> fyi, clisp has all kind of trouble with this. seems like even  
> variable reads are being checked against this marker (!?). i've  
> managed to get a little further by capturing the value into a  
> lambda and going through a funcall, but playing with this can bring  
> down clisp and/or slime.
>

Unfortunately, clisp is allowed to check this. The CLOS MOP spec  
states that the results are undefined if the restrictions on standard- 
instance-access are not met. One of the restrictions is that the slot  
must be bound for standard-instance-access to work. The HyperSpec  
states that "consequences are undefined" means that "conforming code  
must treat the consequences as unpredictable." Specifically, "an  
implementation is permitted to signal an error in this case."

I think this is a case where the authors of the CLOS MOP  
specification weren't careful enough. On the one hand, they say that  
standard-instance-access "is intended to provide highly optimized  
access", but on the other hand, the wording "the results are  
undefined" leaves too much room for implementations. Other  
indications that the authors were a little bit too careless are that  
they haven't specified the respective setf function, and they also  
haven't specified accessors for slots with :allocation :class, which  
makes some implementors decide to add this "feature" to standard- 
instance-access as well.

This is certainly an area that should be fixed in a future version of  
the CLOS MOP specification.


Pascal


-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20061101/e9d54dcc/attachment.html>