I personally don't think that name CL-USER::FOO anyhow represents the "nature" of the symbol
The same number may be referenced as #x20000000 and as 536870912. It's just a way to refer the object, not the object itself. Lets consider and example of symbols use: (defun print-value (value mode) (if (eq mode 'mypkg:lowcase) (format nil "~(~A~)" value) (format nil "~A" value))) So, (print-value "HelLo" 'mypkg:lowcase) returns "hello" Lets suppose someone manipulated packages: uninternet and re-interned MYPKG:LOWCASE. This doesn't break my PRINT-VALUE function, because the contract of my function is not to print lower case value when MODE is a symbols named "MYPKG:LOWCASE", but when MODE is exactly the symbol referred to in PRINT-VALUE. I provided a constant which allows to specify different mode, I provided a way to refer it via package systems as 'MYPKG:LOWCASE. If someone destroyed the mapping, well, the he can't use the name to refer my constant. He should have stored a reference to it, or something. But PRINT-VALUE remains correct. How about this treatment? Best regards, - Anton 03.07.2015, 10:54, "Edi Weitz" <e...@weitz.de>: > Let me repeat: I'm not concerned about whether this could impede my > ability to write CL programs nor am I concerned that some future > implementor might not do the right thing. I just can't see the > internal logic (and the CLHS seems otherwise mostly very clear and > logical to me). > > The standard actually defines the word "same" and says that two > objects are the same if they can't be distinguished by EQL (unless > another predicate is explicitly mentioned). But let's forget about > this definition (although it is hard to talk about such concepts if > you can't use certain words). I'm more concerned with object > identity: > > 1. I guess we all agree that there's one and only one mathematical > object which is the number 536870912. > > 2. We also all know that on some 32-bit implementations (EQ 536870912 > 536870912) can yield NIL while (EQL 536870912 536870912) must yield T. > > 3. So EQL is the preferred predicate in the standard and is intended > to mean that two things are _semantically_ identical although they > might _technically_ be different (like above). > > 4. EQ on the other hand tests whether its arguments are (according to > the CLHS) "the same, identical object." I've always understood this > as a test for identity at the implementation level I shouldn't be > concerned with. (Leaving the question open why EQ is in the standard > at all...) > > 5. Now, and I think this is the crucial part, by using EQ to compare > symbols in various parts of the standard, I take this as a suggestion > that there is for example one and only one symbol CL-USER::FOO like > there is one and only one number 536870912. Even more so, because > they use EQ and not EQL they also suggest - it seems to me - that this > one and only one symbol must have one and only internal > representation. > > 6. But if you agree with #5 and then look at my UNINTERN example how > do you explain the results? Has the symbol which once was > CL-USER::FOO and is still stored in *S* lost its identity? There are > plenty of operations which modify objects - like (SETF GETHASH) - but > none of them causes the object to lose its identity. > > I guess I could rephrase my question like this: Wouldn't it be clearer > if "sameness" of symbols would be defined via EQL with something like: > "Two symbols are EQL if their names are the same under STRING= and > their home packages are the same under EQL." (And maybe some more > sentences if necessary.) > > On Fri, Jul 3, 2015 at 9:16 AM, Anton Vodonosov <avodono...@yandex.ru> wrote: >> I think the most confusing part is what you mean by "same" symbols. >> >> 03.07.2015, 10:10, "Edi Weitz" <e...@weitz.de>: >>> Just out of curiosity and without any relevance in practise: >>> >>> Is there one place in the standard where it is explicitly said that >>> two symbols which are the "same" symbol must be "identical"? I know >>> that there are a couple of examples where this is implied, but >>> formally the examples aren't part of the standard, right? >>> >>> The EQ dictionary entry for example shows this example: >>> >>> (eq 'a 'a) => true >>> >>> and then it continues with this note (emphasis mine): "Symbols that >>> print the same USUALLY are EQ to each other because of the use of the >>> INTERN function." >>> >>> And the entry for INTERN is actually the closest I could find in terms >>> of clarification because it says that if a symbol of a specified name >>> is already accessible, _IT_ is returned -- which sounds like object >>> identity to me. >>> >>> But how does this fit into the picture? >>> >>> CL-USER 1 > (defparameter *s* 'foo) >>> *S* >>> CL-USER 2 > (unintern 'foo) >>> T >>> CL-USER 3 > (defparameter *s2* 'foo) >>> *S2* >>> CL-USER 4 > (eq *s* *s2*) >>> NIL >>> >>> *S* has lost its home package and is thus not EQ to *S2*, sure, but >>> how do we explain this in terms of object identity? Has the UNINTERN >>> operation changed the identity of *S* which once was the one and only >>> CL-USER::FOO but can't be anymore because this role is now occupied by >>> *S2*? >>> >>> Did I miss some clarifying words in the standard? Did I just manage >>> to confuse myself? >>> >>> Thanks, >>> Edi. >>> >>> PS: The UNINTERN entry warns about side effects which could harm >>> consistency, so maybe this is what they meant?