Re: eql => eq?

[HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)]

I have gotten two rejoinders to my comments about the conceptual
usefulness of EQ, both of which explained to me that EQ is not useful
for numbers or any other objects which may be immediate in some
implementations and pointers in others.  I am well aware of that.
Clearly if I am interested either in comparing the values of two numbers
or in seeing whether two general objects will look the same when
printed, EQ is not the right thing to use.  But this has been true back
from the days of Lisp 1.5.  I claim however that there are many cases
where I know that what I am dealing with is in fact a pointer, and what
I want is something that simply checks to see whether two objects are
identical.  In this case, I claim that it is muddying the waters
conceptually to use a primitive that checks for certain kinds of objects
and does tests oriented towards seeing whether they look the same when
printed, act the same when multiplied, or something else.  Possibly it
would be sensible to have a primitive that works like EQ for pointers
and gives an error otherwise.  But if what you are trying to do is to
see whether two literal atoms or CONS cells are the same, I can't see
any advantage to something that works like EQ for pointers and does
something else otherwise.  I can even come up with cases where EQ makes
sense for real numbers.  I can well imagine a program where you have two
lists, one of which is a proper subset of the other.   Depending upon
how they were constructed, it might well be the case that if something
from the larger list is a member of the smaller list, it is a member
using EQ, even if the object involved is a real number. I trust that the
following code will always print T, even if X is a real number.
   (SETQ BIG-LIST (CONS X BIG-LIST))
   (SETQ SMALL-LIST (CONS X SMALL-LIST))
   (PRINT (EQ (CAR BIG-LIST) (CAR SMALL-LIST)))
-------