Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}

[Jon L White <jonl@lucid.com>]

re: Just to clarify what I meant, since as usual I didn't express myself ...

Well me too (i.e. I wasn't as clear as possible).   [Incidentally,
although this topic is only remotely connected to TAILP-NIL, it
seems to be central the to abortive attempt to "clean up" the
EQUAL predicate.  Hence, I drone on some more. ...]

The issue "way back when" wasn't whether EQUAL would be portable and EQ
not portable (since "pdlnums" hadn't even been thought of then), but 
rather whether or not a programmer should be allowed to find out if two
"equivalent" pieces of data are stored in the same location.  The Lisp 
1.5 definition of EQ was "EQUAL, on atoms (meaning, symbols)".  I suppose 
the explanations about "update semantics" forced the hand of those who 
wanted to flush EQ back then.  That is, an EQUAL but non-EQ copy of a cons 
cell wouldn't show the results of updates applied to the original cell.
This kind of analysis is probably more interesting to a pure functional 
programming type, or to a data-flow type person.

Now, as the the EQ/EQL purpose: Interlisp used to have a function called
SETN, which would actually modify the contents of a number "box" --
thus it made sense for Interlisp to have both EQ and EQL (it was called
EQP in Interlisp), to be able to choose whether such updates are to be
considered important.  Of course, Common Lisp has no updators for numbers
or characters -- only new constructors (which is why SETF of LDB is so
complicated) -- so the only conceivable use now for distinguishing EQ
and EQL is explicit storage management.

   (setq pi 3.14159265) ==> 3.14159265
   pi                   ==> 3.14159265
   (setq saved-pi pi)   ==> 3.14159265
   ;; the "Tennessee Patch", in Interlisp-10 code
   (setn pi 3.0)        ==> 3.0
   pi                   ==> 3.0
   (eq pi saved-pi)     ==> T


-- JonL --