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" edi@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:
- I guess we all agree that there's one and only one mathematical
object which is the number 536870912.
- We also all know that on some 32-bit implementations (EQ 536870912
- can yield NIL while (EQL 536870912 536870912) must yield T.
- 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).
- 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...)
- 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.
- 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 avodonosov@yandex.ru wrote:
I think the most confusing part is what you mean by "same" symbols.
03.07.2015, 10:10, "Edi Weitz" edi@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?