[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: EQUAL-STRUCTURE (Version 6)
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: Issue: EQUAL-STRUCTURE (Version 6)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 13 Jan 89 19:26 EST
- Cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <2809618485-9099259@Kelvin>
Date: Thu, 12 Jan 89 11:34:45 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> - Moon contends that standard practice in Symbolics Lisp is
> for instances to be compared using EQ under EQUALP, not by
> descending. There may be performance issues involved here.
> Some agreement needs to be reached.
It is also true on the Explorer that Flavor instances are not descended by
EQUALP. However, I imagine that this was just an oversight in the addition of
EQUALP to the implementation, and am of the opinion that it would be better if
it did compare the components. The only problem I can think of with doing that
is handling unbound slots; perhaps it needs to be specified that two unbound
slots are EQUALP and an unbound slot is never EQUALP to a bound slot.
I really feel that it is badly wrong for EQUALP to descend into
components of "standard-objects." That is an utter violation of
abstraction. Only the designer of the class knows what makes two
objects equivalent. It might depend on information represented
elsewhere than in slots. It might depend on only some of the slots.
Instances of one class might be equivalent to instances of a different
class in some cases. This is not an implementation issue, not a
performance issue, and not an oversight; it is a fundamental issue
of abstraction and semantics.
I see only three ways to cope with this:
(1) Make EQUALP a generic function, and control its behavior with
multimethods.
(2) Make EQUALP do something with standard-objects that's not always
useful and is often dangerous. That could be use EQ, descend, or
signal an error. Of the three, using EQ is best since it's compatible
with EQUAL.
(3) Eliminate EQUALP on the grounds that it is an ill-defined concept.
Instead, use application-specific equality predicates defined by the
user as needed.
Interestingly, the proposal section of the referenced proposal says
that EQUALP is changed to descend into structures, but the discussion
section says that changing EQUALP to descend into structures was
considered and rejected on the grounds that it had serious problems.
I think the discussion is right.