CLOS Response

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

First, they were skeptical about the class precedence list and the wary of
the importance of it. Their concern was that much of the behavior of the
system depended on it while the user couldn't control it easily nor could
a user understand it well.

There was little problem with the topological sorting, and the problems
were with what happened when the explicit rules (a class precedes its
superclasses and the local precedence order is preserved) underconstrained
the ordering. They did not understand the ``tiebreaker.'' The Scheme
people had an interesting proposal: the specification should say that the
CPL is a topological sort of the C and its superclasses subject to the
explicit rules, but that the user could not depend on what happened when
the problem was underconstrained. They proposed that the CPL computation
should explicitly pick a random but valid total ordering when
nondeterminism happens.

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;

	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.

This way the user can specify the ordering without having to write his own
CPL computation function. We could also have some means of using a default
tiebreaker, which would probably be the one we have now. I imagine people would
program by writing defclasses, watching or thinking about what's happening, and
then adding the further constraints to get the desired behavior. The reasonable
behavior of the programming environment tools is important here.

Second, they thought that the complexity of slot description combination
was complex. I agree.

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.

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.

			-rpg-