[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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
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 --
- From: Jim McDonald <email@example.com>
- From: "Robert W. Kerns" <RWK@AI.AI.MIT.EDU>