Do symbols need to be EQ?

[Anton Vodonosov]

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 at 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 <avodonosov at yandex.ru> wrote:
>>  I think the most confusing part is what you mean by "same" symbols.
>>
>>  03.07.2015, 10:10, "Edi Weitz" <edi at 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?