EQUAL

[Jon L White <edsel!jonl@labrea.stanford.edu>]

[apologies for so late a reply -- have been out of town for over a week]

Jim's point about the historical reference of EQUAL seemed to me to be that
it was made to work for the datatypes that were "in common use" in the Lisps
of that day, namely the datatypes necessary for writing programs in the 
Lisp language.  Hence, conses, symbols, numbers, maybe strings, and not 
much else.

However, I certainly wouldn't expect anything productive to come from a 
discussion on how to determine whether two programs/functions  *really*  
are "equal"!   Possibly you took MacDonald's argument to an extreme that 
he didn't originally intend?

What would be the objections to extending EQUAL to accommodate the serious 
modern datatypes of Common Lisp? in particular:

   (1) Do component-wise EQUAL comparisons on arrays [this implies "descent"
       for pointer arrays].  Unlike with EQUALP, the arrays must be of the 
       same type, but the presence of fill-pointers,  array-element-type
       "upgrading", adjustability, and displacement may require some 
       refinements of this clause.

   (2) Descend defstructs, except possibly for "system" defstructs that
       are built-in by the implementation [i.e., an implementation can
       use defstruct to implement a STREAM, but impose a "private"
       definition of EQUAL for streams; probably same for all types 
       discussed in the cleanup issue TYPE-HIERARCHY-UNDERSPECIFIED].  
       Possibly extend defstruct to admit an option :equal, similar to 
       the :copier option, but this isn't a critical requirement now.

   (3) Require that EQUAL be a "generic" function, so that CLOS methods
       can be written for it; likely, the "default" method for non-built-in
       classes would be some sort of error, meaning that mindless descent
       isn't a good default.  By analogy with defstructs, you can compare
       two defstuct-instances of the same type with the :equal functions,
       and you could only compare two clos instances for which there is an 
       appropriate EQUAL method supplied.


This definition would imply that hashtables of :type EQUAL will operate in
the manner expected by so many users of Common Lisp.  Somehow, people have
been lured into thinking that this is already the current practice; but of 
course something much more limiting is the current state.


Finally, I might point out that recent discussions about EQUALP seem to 
have overlooked it's variations on numerical equality and array-type
indifference.  Extending EQUAL to descend structures is *not* the same 
as retracting EQUALP to be case-sensitive.


-- JonL --