<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 3:09 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">Just out of curiosity and without any relevance in practise:<br>
<br>
Is there one place in the standard where it is explicitly said that<br>
two symbols which are the "same" symbol must be "identical"?  I know<br>
that there are a couple of examples where this is implied, but<br>
formally the examples aren't part of the standard, right?<br>
<br>
The EQ dictionary entry for example shows this example:<br>
<br>
  (eq 'a 'a)  =>  true<br>
<br>
and then it continues with this note (emphasis mine): "Symbols that<br>
print the same USUALLY are EQ to each other because of the use of the<br>
INTERN function."<br>
<br>
And the entry for INTERN is actually the closest I could find in terms<br>
of clarification because it says that if a symbol of a specified name<br>
is already accessible, _IT_ is returned -- which sounds like object<br>
identity to me.<br>
<br>
But how does this fit into the picture?<br>
<br>
  CL-USER 1 > (defparameter *s* 'foo)<br>
  *S*<br>
  CL-USER 2 > (unintern 'foo)<br>
  T<br>
  CL-USER 3 > (defparameter *s2* 'foo)<br>
  *S2*<br>
  CL-USER 4 > (eq *s* *s2*)<br>
  NIL<br>
<br>
*S* has lost its home package and is thus not EQ to *S2*, sure, but<br>
how do we explain this in terms of object identity?  Has the UNINTERN<br>
operation changed the identity of *S* which once was the one and only<br>
CL-USER::FOO but can't be anymore because this role is now occupied by<br>
*S2*?<br>
<br>
Did I miss some clarifying words in the standard?  Did I just manage<br>
to confuse myself?<br></blockquote><div><br></div><div>I think you manged to confuse yourself. unintern of course did not change the identity of *s* (by which we are meaning the symbol bound to *S*) -- identity is identity is identity. Unintern did, however, change the package  of *s*, so (as one side-effect) a new symbol of the same name in the same package is a new object (identical to nothing at birth).</div><div><br></div><div>Perhaps the problem is confusing the levels of abstraction offered by (a) EQ and (b) object identity. The latter is a very simple idea. EQ, as you adroitly demonstrated, worries about all sorts of things, including a symbol's package.</div><div><br></div><div>my2 anyway.</div><div><br></div><div>-kt</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Edi.<br>
<br>
PS: The UNINTERN entry warns about side effects which could harm<br>
consistency, so maybe this is what they meant?<br>
<br>
</blockquote></div><br><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></div>