<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 1 Nov 2006, at 11:11, Attila Lendvai wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><DIV style=""><DIV><DIV>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: </DIV><DIV><BR></DIV><DIV>(defclass test ()</DIV><DIV> (test-slot))</DIV><DIV><BR></DIV><DIV>(defvar +unbound-slot-value+</DIV><DIV> (let ((test (make-instance 'test)))</DIV><DIV> (standard-instance-access test</DIV> <DIV> (slot-definition-location</DIV><DIV> (find 'test-slot (class-slots (find-class 'test))</DIV><DIV> :key #'slot-definition-name)))))</DIV><DIV><BR></DIV><DIV>(setf (find-class 'test) nil)</DIV> <DIV><BR></DIV><DIV>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).</DIV></DIV></DIV></BLOCKQUOTE><DIV><BR>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. <BR><BR class="khtml-block-placeholder"></DIV></DIV></BLOCKQUOTE><BR></DIV><DIV>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."</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is certainly an area that should be fixed in a future version of the CLOS MOP specification.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Pascal</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>-- </DIV><DIV>Pascal Costanza, <A href="mailto:pc@p-cos.net">mailto:pc@p-cos.net</A>, <A href="http://p-cos.net">http://p-cos.net</A></DIV><DIV>Vrije Universiteit Brussel, Programming Technology Lab</DIV><DIV>Pleinlaan 2, B-1050 Brussel, Belgium</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>