Do symbols need to be EQ?

[Steve Haflich]

Symbols must behave under EQ as they traditionally always have if symbols
are to be useful as property list indicators.

There is a semantic issue that is not explicit in the ANS but which
underlie language semantics and the concepts of "same", "identical", and
"equivalent".  It concerns object mutability.

The only objects for which the EQ/EQL distinction is unspecified are
characters and numbers.  But hese objects are immutable (at least in the
portable language).  Most other kinds of objects, including symbols, are
mutable.  The fundamental principle of "identical" is that if two objects
are EQ, mutating one of them [sic] will necessarily mutate the other.  If
two objects are _not_ EQ, then mutating one will _not_ mutate the other.

I would propose that since symbols have several mutable properties,
mutating a property of one reference to a symbol will mutate that property
of another reference iff those two references are EQ.  The "only if" part
of "iff" is here crucial.  This is exactly the same as for conses, arrays,
structure slots, hashtables, readtable dispatches, etc. etc. etc.

It still isn't clear whether this obvious semantic property can be proven
from the ANS.


On Fri, Jul 3, 2015 at 2:49 PM, Anton Vodonosov <avodonosov at yandex.ru>
wrote:

> 03.07.2015, 15:45, "Martin Simmons" <martin at lispworks.com>:
> >>>>>>  On Fri, 03 Jul 2015 12:15:32 +0300, Anton Vodonosov said:
> >>  Envelope-From: avodonosov at yandex.by
> >>
> >>  I want to correct myself. Unlike numbers or any other objects,
> >>  symbols _are_ about names, so we can say that the name CL-USER::FOO
> >>  represents the "nature" of symbol.
> >>
> >>  I think Common Lisp wants to save memory and speedup comparison,
> >>  so when we use the same name we get the same object, as implemented
> >>  by INTERN (this trick even has name - the Flyweight pattern).
> >>
> >>  So, this is just an optimization trick, and UNITERN is a maintenance,
> >>  system tool, not designed to express programs. We are encouraged to
> >>  operate as if the symbol name means the same object.
> >
> > I disagree about it being to save memory -- a CL symbol is an object with
> > mutable attributes, so identity is important.
>
> This is part of the optimization. Functions like SYMBOL-VALUE, GET could
> be, for example, backed by hash maps from symbol name, thus returning
> the same value for equally named symbols.
>
> I mean on the level of abstraction mathematicians use when they say
> "let X = 10" it means that the textual name X is bound to 10.
> In Common Lisp it means that the symbol object with name X is bound to 10.
>
> So, in general, abstract sense, symbols need not to be EQ.
> But Common Lisp distinguishes symbols up to their object instance identity.
> I still suppose this choice is an optimization.
>
> > Also, the identity of uninterned symbols is just as important (e.g. for
> macros)
> > as interned ones
>
> I think if symbols were compared by their names instead of EQ, the
> were ways to satisfy needs of macros. But that would be another language,
> not CL.
>
> Best regards,
> - Anton
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20150703/92abaa73/attachment-0001.html>