<div dir="ltr">Package = map from symbol name to symbol object.<div>INTERN ~= (or (gethash ...) (setf (gethash ...)))</div><div>UNINTERN ~= remhash</div><div><br></div><div>There's nothing special about symbols. You'd get the same effect with a map of constants and operations to add/remove them from the map.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 10:56 AM, Kenneth Tilton <span dir="ltr"><<a href="mailto:ken@tiltontec.com" target="_blank">ken@tiltontec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 4:48 AM, Edi Weitz <span dir="ltr"><<a href="mailto:edi@weitz.de" target="_blank">edi@weitz.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Perhaps the excerpt below (from a fresh LW image) makes more obvious<br>
what my "philosophical problem" is. I have redacted the output of<br>
DISASSEMBLE to only show the relevant parts. It shows that EQ is<br>
essentially just one simple comparison with a machine word (which is<br>
what I expected). It also shows that I get the same machine word<br>
again as long as I don't mess around with UINTERN or something. But<br>
once I've done that, I get _another_ machine word and so in terms of<br>
simple-minded EQ I get a different object.<br>
<br>
CL-USER 1 > (defun foo-1 (x)<br>
(eq x 'bar))<br>
FOO-1<br>
CL-USER 2 > (disassemble 'foo-1)<br>
;; ...<br>
21: 3DF771F921 cmp eax, 21F971F7 ; BAR<br>
26: 750D jne L3<br>
;; ...<br>
NIL<br>
CL-USER 3 > (defun foo-2 (x)<br>
(eq x 'bar))<br>
FOO-2<br>
CL-USER 4 > (disassemble 'foo-2)<br>
;; ...<br>
21: 3DF771F921 cmp eax, 21F971F7 ; BAR<br>
26: 750D jne L3<br>
;; ...<br>
NIL<br>
CL-USER 5 > (unintern 'bar)<br>
T<br>
CL-USER 6 > (defun foo-3 (x)<br>
(eq x 'bar))<br>
FOO-3<br>
CL-USER 7 > (disassemble 'foo-3)<br>
;; ...<br>
21: 3DAB71F921 cmp eax, 21F971AB ; BAR<br>
26: 750D jne L3<br>
;; ...<br>
NIL<br>
<br>
</blockquote></div><br></div></div>Sorry, where is the problem? The spec is clear that a new object (with a new pointer) will be created given the unintern hijinx, so all is consistent: different pointer, EQ->nil.</div><div class="gmail_extra"><br></div><div class="gmail_extra">ie, It is not just "in terms of EQ" that you have a different object: you have created two distinct pointer objects (and EQ dutifully says so).</div><div class="gmail_extra"><br></div><div class="gmail_extra">And at a higher level of abstraction, you have created two different symbols, one interned and one not.</div><span><div class="gmail_extra"><br></div><div class="gmail_extra">-kt<br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Kenneth Tilton</div><div dir="ltr">54 Isle of Venice Dr<br><div>Fort Lauderdale, FL 33301</div><div><br></div><div><a href="mailto:ken@tiltontec.com" target="_blank">ken@tiltontec.com</a></div><div><a href="http://tiltontec.com" target="_blank">http://tiltontec.com</a><br></div><div><span style="font-size:12.8000001907349px">@tiltonsalgebra</span><br></div><div><br></div><div><a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077</a></div><div><br></div><div>"In a class by itself." <i>-Macworld</i></div><div><br></div><div><br></div></div></div></div></div></div>
</div></span></div>
</blockquote></div><br></div></div>