CLOS Response

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

    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
    points.

I think this feedback is valuable, but should be put into perspective.
Comments below.

    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
    nondeterminism happens.

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
    things.

	    1. There should be a flag that controls when the system warns about
	       nondeterminism;

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.