Re: Issue EQUAL-STRUCTURE

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

> I firmly believe that specifying component-wise processing as the default
> for any protocol applicable to user defined classes is wrong.  Without an
> understanding of a class there is no way to know which features of
> an instance are 'interesting' and which are merely artifacts of the
> implementation, or even how to find the interesting features (they
> may not be stored as elements in the instance).

I know I shouldn't enter such debates at such a late date, but I don't
think this issue is as clear-cut as some seem to believe.  While what
Kim says about instances is true, we have to remember that that we're
talking about EQUALP.  EQUALP isn't supposed to do the one true right
thing; it's just supposed to be a sometimes useful combination.  And
no one has to use it when it's inappropriate.  Many users want an
equality comparison that descends structs, and they used to have one
(thought they may not have known it).

The whole argument turns around structs being user-defined classes.
After all, we're all willing to allow EQUALP on lists; and even for
lists there's no way to be sure what parts are really significant
(because, as always, this information is in the programmer's head)
or where all parts are kept (hash tables work for lists too).

But consistency with instances of classes with metaclass standard
class is just one of the factors we have to consider.  Is it better
(or more useful) to make struct classes be like standard classes
minus some flexibility or to make them like structures in the old
sense plus the ability to define methods?

-- Jeff