[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
eql => eq?
- To: common-lisp at SU-AI
- Subject: eql => eq?
- From: DILL at CMU-20C
- Date: Mon, 25 Jan 1982 22:57:00 -0000
Proposal: rename the function "eq" in common lisp to be something like
"si:internal-eq-predicate", and the rename "eql" to be "eq". This would
have several advantages.
* Simplification by reducing the number of equality tests.
* Simplification by reducing the number of different versions of
various predicates that depend on the type of equality test you
want.
* Greater machine independence of lisp programs (whether eq and equal
are the same function for various datatypes is heavily
implementation-dependent, while eql is defined to be relatively
machine-independent; furthermore, functions like memq in the current
common lisp proposal make it easier to use eq comparisons than eql).
Possible disadvantages:
* Do people LIKE having, say, numbers with identical values not be eq?
If so, they won't like this.
* Efficiency problems.
I don't believe the first complaint. If there are no destructive
operations defined for an object, eq and equal ought to do the same
thing.
The second complaint should not be significant in interpreted code,
since overhead of doing a type-dispatch will probably be insignificant
in comparison with, say, finding the right subr and calling it.
In compiled code, taking the time to declare variable types should allow
the compiler to open-code "eq" into address comparisons, if appropriate,
even in the absence of a hairy compiler. A hairy compiler could do even
better.
Finally, in the case where someone wants efficiency at the price of
tastefulness and machine-independence, the less convenient
implementation-dependent eq could be used.
-------