[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eql => eq?
- To: HEDRICK at RUTGERS
- Subject: Re: eql => eq?
- From: DILL at CMU-20C
- Date: Fri, 29 Jan 1982 16:21:00 -0000
- Cc: common-lisp at SU-AI
- In-reply-to: Your message of 27-Jan-82 1332-EST
If an object in a Common Lisp is defined to have a particular type of
semantics (basically, you would like it to be an "immediate" object if
you could only implement that efficiently), programmers should not have
to worry about whether it is actually implemented using pointers. If
you think about your data structures in terms of pointers in the
implementation, I contend that you are thinking about them at the wrong
level (unless you have decided to sacrifice commonality in order to
wring nanoseconds out of your code). The reason you have to think about
it at this level is that the Lisp dialect you use lets the
implementation shine through when it shouldn't.
With the current Common Lisp definition, users will have to go to extra
effort to write implementation-independent code. For example, if your
implementation makes all numbers (or characters or whatever) that are
EQUAL also EQ, you will have to stop and force yourself to use MEMBER or
MEM instead of MEMQ, because other implementations may use pointer
implementations of numbers (or worse, your program will work for some
numbers and not others, because you are in a maclisp compatibility mode
and numbers less than 519 are immediate but others aren't). My belief
is that Common Lisp programs should end up being common, unless the user
has made a conscious decision to make his code implementation-dependent.
The only reason to decide against a feature that would promote this is
if it would result in serious performance losses.
Even if an implementation is running on a VAX, it is still possible to
declare data structures (with the proposed "THE" construct, perhaps) so
that compiler can know to use the internal EQ when possible, or to use a
more specific predicate. It is also not clear if compiled code for EQL
has to be expensive, depending on how hard it is to determine the type
of a datum -- it doesn't seem totally unreasonable that a single
instruction could determine whether to use the internal EQ (a single
instruction), or the hairier EQL code.
In what way is this "turning Lisp into Ada"?