[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
equality of structures
- To: COMMON-LISP@sail.stanford.edu
- Subject: equality of structures
- From: firstname.lastname@example.org
- Date: Mon, 09 Nov 87 12:00:35 PST
- Cc: email@example.com
- Posted-date: Mon, 09 Nov 87 12:00:35 PST
- Sender: firstname.lastname@example.org
From the standpoint of writing TRANSFORMATIONs on common lisp programs,
it would be preferable to have EQUAL well defined for structure
instances for which no :type (too bad that wasn't called :implementation)
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?