[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: CLOS Response
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 19 Feb 87 19:58 EST
- In-reply-to: The message of 19 Feb 87 16:23 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Date: 19 Feb 87 1323 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Monday I presented CLOS to the SmallTalk and Scheme folks at Tektronix in
Beaverton, Oregon. The response was disappointing, though one would expect
SmallTalk people to respond negatively. However, they made some good
I think this feedback is valuable, but should be put into perspective.
First, they were skeptical about the class precedence list and the wary of
the importance of it....They proposed that the CPL computation
should explicitly pick a random but valid total ordering when
I sent mail in November with some strong arguments for why this won't work.
I think it was November; I can dig up the exact message reference if you like.
This radical suggestion can be made palletable by adding the following
1. There should be a flag that controls when the system warns about
We could do this if we didn't mind adding extra complexity to the standard.
It would have to be a class option, not a global flag, so that classes using
both styles could coexist in the same Lisp.
2. There should be a new class option which is of this form:
(:relations (C1 C2) ... (Cn-1 Cn)) in DEFCLASS which give
further constraints to the ordering of superclasses.
Flavors has this but there didn't seem to be much interest in putting it into
the standard. Should we reconsider that decision, or would that be making
the standard too complex?
Second, they thought that the complexity of slot description combination
was complex. I agree.
The description in the document is horrendously overcomplicated. The
previous attempt was much simpler but still too hard to understand and
imprecise. For some reason we've had great difficulty explaining this
concept, even though it is actually rather simple. I've been planning on
mailing out a proposed better way of explaining slot inheritance for
discussion, but haven't had time to finish it yet. In any case something
clearly has to be done.
Third, they thought that method combination was complex. Because we all
seem to agree that method combination is important, this probably
indicates a different presentation methodology or a different organization
to the system is desirable. One suggestion is to present CLOS so that it
looks as much like CommonLoops as possible at first glance and to then
bring in method combination. That is, maybe a good idea is to break up
the current first chapter into two chapters where the first chapter
defines only unqualified methods along with the behavior of methods under
CALL-NEXT-METHOD. The second chapter could show what happens when methods
are qualified using standard method combination.
This is the reaction one would expect from people used to Smalltalk's
send-to-super mechanism. I think you would find the analogous reaction, that
the call-next-method feature is complex and should be relegated to the back
of the book, if you presented it to people who were used to method combination.
I think the order of presentation should be left the way it is and we should
concentrate on the remaining substantial issues that need to be resolved.
At least a conceptual simplicity in presentation must be maintained. LGD
and I only cleaned up the description of method combination enough that it
was not grossly inconsistent, and I think it needs a major amount of
thought to present it well.
I thought we were trying to be precise with this document, rather than trying
to be easy to understand.