[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: EQUAL-STRUCTURE (Version 5)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: EQUAL-STRUCTURE (Version 5)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Sat, 1 Oct 88 19:39 EDT
Per Masinter's request, here's a version with my comments edited in.
- Changed wording of EQUALP portion of Proposal to change
"CLOS instance" to "instance" and "defstruct instance" to "structure".
- Added Cleanup committee endorsement for option STATUS-QUO in Discussion.
- Added editorial advice in Discussion.
References: EQUAL (p80), EQUALP (p81)
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, and it
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives. Aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''