<div dir="ltr">Symbols must behave under EQ as they traditionally always have if symbols are to be useful as property list indicators.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It still isn't clear whether this obvious semantic property can be proven from the ANS.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 2:49 PM, Anton Vodonosov <span dir="ltr"><<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">03.07.2015, 15:45, "Martin Simmons" <<a href="mailto:martin@lispworks.com">martin@lispworks.com</a>>:<br>
<span class="">>>>>>>  On Fri, 03 Jul 2015 12:15:32 +0300, Anton Vodonosov said:<br>
>>  Envelope-From: <a href="mailto:avodonosov@yandex.by">avodonosov@yandex.by</a><br>
>><br>
</span><span class="">>>  I want to correct myself. Unlike numbers or any other objects,<br>
>>  symbols _are_ about names, so we can say that the name CL-USER::FOO<br>
>>  represents the "nature" of symbol.<br>
>><br>
>>  I think Common Lisp wants to save memory and speedup comparison,<br>
>>  so when we use the same name we get the same object, as implemented<br>
>>  by INTERN (this trick even has name - the Flyweight pattern).<br>
>><br>
>>  So, this is just an optimization trick, and UNITERN is a maintenance,<br>
>>  system tool, not designed to express programs. We are encouraged to<br>
>>  operate as if the symbol name means the same object.<br>
><br>
> I disagree about it being to save memory -- a CL symbol is an object with<br>
> mutable attributes, so identity is important.<br>
<br>
</span>This is part of the optimization. Functions like SYMBOL-VALUE, GET could<br>
be, for example, backed by hash maps from symbol name, thus returning<br>
the same value for equally named symbols.<br>
<br>
I mean on the level of abstraction mathematicians use when they say<br>
"let X = 10" it means that the textual name X is bound to 10.<br>
In Common Lisp it means that the symbol object with name X is bound to 10.<br>
<br>
So, in general, abstract sense, symbols need not to be EQ.<br>
But Common Lisp distinguishes symbols up to their object instance identity.<br>
I still suppose this choice is an optimization.<br>
<span class=""><br>
> Also, the identity of uninterned symbols is just as important (e.g. for macros)<br>
> as interned ones<br>
<br>
</span>I think if symbols were compared by their names instead of EQ, the<br>
were ways to satisfy needs of macros. But that would be another language,<br>
not CL.<br>
<br>
Best regards,<br>
- Anton<br>
<br>
</blockquote></div><br></div>