[Re: EQUAL]

[goldman@vaxa.isi.edu]

   My original response to part of JonL's suggestion regarding CLOS and
   EQUAL:
	First, I would think that (OBJECT OBJECT) would have an EQUAL method
	that applied EQL, not ERROR, and that method would inherit to all standard
	classes under OBJECT.  I must misunderstand your intent -- you certainly
	would want EQUAL to be TRUE whenever EQ was true, not an error?
    
   JonL's comment on that:
    I'm not 100% certain that one would want this.  Perhaps the CLOS subcommittee
    of x3j13 will tackle it.  Mostly, the default method is just to say that
    you shouldn't be doing this (calling EQUAL) on an object of this type.  But 
    just having no applicable method may in fact be a better kind of error.  Of 
    course, a default method could check for EQ before causing any other kind of 
    error.



But because EQUAL is defined to recur to components of certain compound
objects, saying that it is an error to call EQUAL on objects of type C
implies that it would be an error to call it on compound objects (say,
lists) containing Cs.  It seems wrong to me NOT to be able to choose to
represent something with a CLOS object if you want to use it in a list, or
array, or struct, that is going to tested with EQUAL.

I would feel far better if EQ, EQL, EQUAL, and EQUALP (the built-in
equivalence predicates) were well defined (no errors) over the entire
universe of lisp objects.  This does not imply that one couldn't
make EQUAL a generic function;  only that it would "be an error" to
write EQUAL methods that destroyed the properties of EQUAL that make it a
universal equivalence predicate.  [Like, I'd be very suspicous
of any method with different specializers for the two arguments.]

Neil