> 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.
[...]
> Did I miss some clarifying words in the standard? Did I just manage
> to confuse myself?
I think the confusion here is because you're confounding the reader path to a
symbol with the idea of the symbol itself. And honestly, most of the "Packages"
chapter is written in a way that doesn't help (e.g., UNINTERN calling a symbol
with no package "pathological").
First of all, just ignore packages completely. They are but glorified hash
tables, as the first sentance of the Packages chapter tries to make clear: "A
package establishes a mapping from names to symbols"
Instead, consider just the symbol type. Symbols are structured objects, just
like any other. They have slots for their name, for their value, for their
function value, for their properties list, and for their (optional) home
package. You make them with MAKE-SYMBOL, and you copy them with COPY-SYMBOL.
AFAIK, the examples given for COPY-SYMBOL are the clearest attempt the spec
makes to establish this as the conceptual model.
The reason that EQL doesn't do anything special for symbols the way it does for
numbers is that symbols have structure. Symbols have names, home packages,
property lists ... all sorts of things that you can destructively modify. The
trick with EQL and numbers only works if you can't change anything about an
object. Symbols being proper objects, object identity is the only thing you can
use. INTERN and UNINTERN are just GETHASH and REMHASH under the hood.
Of course, the above is just the model; implementations can do anything they
want that doesn't break the model, and the spec tries to use lots of
formulations and careful, confusing wording to leave implementations the most
freedom.
Cheers,
Thomas
