Do symbols need to be EQ?

[Jason Cornez]

Sorry this is arriving late - I had some trouble posting to the group yesterday.

-Jason

On 07/03/2015 10:21 AM, Kenneth Tilton wrote:
> Perhaps the problem is confusing the levels of abstraction offered
> by (a) EQ and (b) object identity. The latter is a very simple
> idea. EQ, as you adroitly demonstrated, worries about all sorts of
> things, including a symbol's package.

I don't think that anything has demonstrated that EQ is worried about
anything other than object identity.  And 5.3.33 is pretty clear that
this is all that EQ does

"Returns true if its arguments are the same, identical object;
otherwise, returns false."

As for symbols, I agree that unintern does NOT affect identity of a
symbol.  At the repl...

(defparameter *a* 'foo)
(defparameter *b* 'foo)
(eq *a* *b*) ==> T
(unintern 'foo)
(eq *a* *b*) ==> T
(defparameter *c* 'foo)
(eq *a* *c*) ==> NIL

If there is some doubt about why the last form is NIL, it is because
when the (defparameter *c* 'foo) form is _read_, the reader creates a
new symbol (via intern) because there is no current symbol named "FOO"
in the current package - obviously, we just uninterned the previous
symbol which is still the value of *a* and *b*.

The same thing is going on in the case of a function that refers to a
symbol.  The symbol won't change, unless the function text is _read_
again.

(defun func-foo (sym)
 (when (eq sym 'foo)
    ...))

If you pass in the same symbol object, EQ will always return T.  But
sure, if you unintern 'foo and then at the repl call (func-foo 'foo),
you are now passing in a brand-new symbol, and so of course EQ will
return NIL in that existing function.

Hope this helps,
-Jason