[no subject]

Personally, I would like  the definition should be:
  two instances are EQL iff they are EQ
  two instances are EQUAL iff
    a) they are instances of the same most specific structure type, and
    b) the contents of all corresponding fields are EQUAL.

[This is like the current definition of EQUALP for un:TYPEed structures,
at least if you believe structures are objects that have components
-- see CLtL's definition  of EQUALP.]

[However, I suspect that most implementors would rather have it defined
like to have these objects be EQUAL iff they are EQL, so they can 
be implemented as arrays.]

This entire problem, I am sure, stems from the more fundamental "problem"
that EQUAL is defined to recur into components of lists, but NOT of arrays,
-- except for STRINGs and BIT-VECTORs -- a decision that could ONLY have its
roots in implementation considerations. 

An alternative  suggested by the earlier message, 
a *default-structure-type* variable, implies making the definition of
EQUAL implementation specific.  But I think it carried along with it an
implication that implementations are limitied to defaulting the
implementation of such structure instances
to the equivalent of what results from either :ARRAY or :LIST, and to 
defaulting the implementation of ALL instances the same way.


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?)  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?

Neil