EQ

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

re: If neither operand is a constant or a type-declared variable or function 
    call, it is not known whether the EQL call may be optimized into an EQ 
    call.  (This is probably not a problem for your implementation, JonL, or 
    for many others', but it may be for others - it is for mine.)  

I think that's a universal problem, but not a particularly serious one.
Of course, Lucid's Production-Quality compiler makes all the obvious type 
optimizations; but for EQL, it also does an in-line check for EQ success 
before calling EQL out-of-line.  (Vax/NIL used to do a bit more on EQUAL, 
based on monitoring some MACSYMA code; but that was before EQL came about).

I have often referred to these kinds of tricks as "beating out the function 
call" -- namely, a fast, in-line, fail-safe, but not complete test which is 
performed just before taking the time to go out-of-line.  I think Richard 
Fateman of UCB independently discovered "beating out the function call" on 
EQUAL -- for exactly the same reason (tuning the performance of Vaxima).

Internally, Lucid code ocasionally makes use of (optimizable) functions
named EQ-FOR-EQL-P and EQ-FOR-EQUAL-P; typically they are used to select
one of two alternative methods;  e.g., ASSOC can dynamically turn into
ASSQ.  These checks "open compile".  So the time to make the determination
pays off immensely in the one case by reducing out-of-line calls, and in
the other case, the out-of-line calls are so costly that the check time
is negligible.  It wouldn't matter whether or not EQ were part of the 
portable standard -- these tricks would still be applicable to the way in 
which the system internals and compiler output work.

A good point to make for retention of EQ is that even though portable
code may not be able to utilize the difference between EQ and EQL, it
will still be the case that every implementation will have *some*
function that does address/pointer identity comparison; so we might as 
well all call it the same thing, so as to minimize the culture shock when
moving from one implementation to another.


-- JonL --