questions about CLOS [original subject: equality of structures]

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 09 Nov 87 12:00:35 PST
    From: goldman@vaxa.isi.edu

    Re:  the suggestion that CLOS should subsume (by convention or otherwise)
    uses of un:TYPEed defstruct types? 
      I presume that this takes care of the issue of EQUAL, because the CLOS
    specifies the semantics of EQUAL for its class instances?  (What is the
    specification, by the way?)  

CLOS does not currently say anything about how the functions EQUAL, EQUALP,
and EQL behave on instances of standard classes (you can read the last four
words as equivalent to "user-defined objects").  It also doesn't say
anything about the type-specific equality functions CHAR-EQUAL,
CHAR-NOT-EQUAL, TREE-EQUAL, STRING-EQUAL, and STRING-NOT-EQUAL, nor
the 6 type-specific = and /= functions.

It would fit the structure of CLOS to say that EQUAL and EQUALP will be
expanded to generic functions whose behavior can be extended by defining
methods.  I don't think we would want to allow extending EQL or the
type-specific functions, since CLOS does not claim to be so powerful as
to allow you to create new types of numbers, characters, or strings.
Extending EQ would not make any sense, of course.

I suspect the reason CLOS currently shys away from EQUAL and EQUALP is
that the equality predicates in Common Lisp are clearly not very well
chosen and beg for a lot of cleaning up based on a better theory of what
we want.  To give just one example, it's peculiar that comparing arrays
element-by-element has been bundled together with ignoring alphabetic case.
It's probably better to wait for Common Lisp to get its act together
before extending CLOS into this area; clearly, equality methods can be
added later to the standard or to an individual implementation without
any incompatibilities, so there's no rush.

A possible additional reason is that CLOS does not deal terribly well
with symmetric two-argument functions such as EQUAL.  It's possible to
specialize them, but you usually have to define a lot of seemingly
extraneous methods, since the generic function dispatch mechanism has
no concept of commutativity nor of type translation.

				 But I would be loathe to replace my un:TYPEed
    defstructs with DEFCLASSes if I gave up substantial efficiency when I only
    wanted the limited power provided by the "record structure" semantics.
    Are there enough declarations available in CLOS so that I could get
    my compiled accesses to slots of such instances down to the equivalent
    of an array element reference?

As an implementation-independent language specification, CLOS does not
and cannot directly address this issue.  However, it's clear what would
generally need to be declared to allow implementations to do something
like that, although you would have to look at each individual implementation
to see whether it was faster or slower than arrays with declarations;
you might even find an implementation where slot access was faster than
array access even without declarations.  Basically what you need to declare
is that the class cannot be redefined or subclassed.  Some members of the
CLOS subcommittee volunteered to propose declaration names and syntaxes
to allow for this type of optimization, but they haven't finished yet.
However, it is intended that most CLOS implementations either be very
efficient or have a way to make them very efficient through declarations.