Meeting Next Week

[Gregor.pa@Xerox.COM]

    Date: 11 Dec 87 13:12 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    My reaction to the supplied chapter 3 is mixed. Let me outline it
    briefly:

As usual, I have only included the parts of your message I am actually
replying to.

(actually Danny and I both wrote this, but the current state of text
editors is such that I can't say "M-X Pluralize Author")

    1. I am uncomfortable with the common-base (or subtractive) philosophy. I
    believe it to be a priori incorrect though practical. I would submit for
    consideration a modification, which is that the meta-object protocol be in
    terms of the large classes (standard-class and friends) but that the
    ontology of those classes be unspecified. That is, I think we can leave
    open the question as to whether standard-class is a diamond or an
    accumulation of mixins - making that an implementation choice - and also
    leave open whether extensions to the protocol based on mixins from
    constituent classes is possible.

    As important as what is said in a specification is what is unsaid.

I think this is a good point.  Certainly we could leave specific
implementations free to modularize standard class any way they want.
Also, there is no doubt that we are all uncomfortable with the
common-base design.  As I have said before, the question is not "is
there something better" the question is "do we have enough experience to
come up with something better, or is that going to take a few years".

    2. Although the meta-object protocol is advertised as an interpreter - which
    seems to be a good presentation mechanism at least - there is no explicit
    picture of what that interpreter is like. Possible situations would be
    an informal description, a set of constraints, or an actual piece of
    pseudo-code. Without such an overview, it is very difficult to get the
    big picture from chapter 3.

Its true that chapter 3 doesn't give a very good overview.  I think we
can do better than what is there.  We haven't addressed that issue too
much since because we had PCL out there to do that job for us.

    3. I fear that too much hidden detail exists. For example, there is a casual
    mention of a ``class name table'' in the description of ADD-NAMED-CLASS. This
    term is nowhere mentioned, and it is not clear whether this is a thing that
    must exist in every CLOS or whether this is a device in the possibly
    fictitious interpreter.

That is just symbol-class.

    4. There is too little orthogonality between objects and names.
    ADD-NAMED-CLASS would seem to require a name and a class as arguments, yet
    it takes a prototype instance, a name, and a bunch of stuff for making up
    a class. I would have guessed that ADD-NAMED-CLASS is a combination of
    UPDATE-CLASS and something else. The fact that it might be necessary to
    package name and object handling into one place strikes me as a hint
    of tangled design.

I believe the distinction between classes and names is quite well drawn.
The reason add-named-class has such a complex behavior is because it
must implement the semantics of:

  (if <class-exists-p>
      <update it as described in chapter 1>
      <define a new one as described in chapter 1>)

The layer underneath the named layer deals with the class and generic
function objects anonymously.  Except for the generic functions for
which it is explicitly stated that they deal with names, they all deal
with anonymous objects.  Anything that can be done with a named object
can be done with an anonymous object, including the find and update
protocol which defclass provides for named objects.

    5. The existence of prototype instances all over gives me the feeling that
    the descriptive mechanism for methods is poor. It appears that these
    prototypes mostly solve the problem of arranging for a method on some
    superclass to be selectable where (defethod f ((class (eql C1))...) would
    not work.  Since we have dirtied the language with EQL already, how about
    (defmethod foo ((class (at-most C1)))...) which means that CLASS must be
    a class that is either C1 or a subclass of C1?

Right.  I think we have all known for some time that sometimes 'dummy'
arguments are passed to methods to make the method lookup work.  Thats
why we added the feature to defmethod to make specialized arguments be
'referred to'.  We could consider adding this new kind of specializer
now, but I think its a little late in the game for that.  Prototype
instances, even though a little ugly, are simple and work.

    7. My impression is that the proposed protocols are good for making
    OOP systems that are almost exactly like CLOS but bad for anything
    different. The subtractive philosophy advertises that.

Well, we have a fair amount of empirical evidence that suggests that
this protocol can be used to make systems that are fairly different than
CLOS.  I think we got a pretty clear inidication of that at the OOPSLA
workshop.  There is also a fair amount of other work we have seen that
reinforces this.  That work has had a significant influence on this
design, we believe the design outlined in chapter 3 is much better than
the design currently implemented in PCL.

Of course there is the question of what 'almost exactly like CLOS' and
'fairly different than CLOS' mean.  Clearly there must be many systems
that no metaobject protocol we could write would provide adequate
support for.

    8. Of course we need better names for things than names like Collect-slotDs.
    But I suspect that DannyB and GregorK won't object.

Of course.

    10. Too much emphasis has gone into making portable implementations of
    CLOS possible. Because there is no portable way to extend the Common Lisp
    type system doesn't mean that we must outlaw things that could be done in
    a Common Lisp in which that is possible. There must be a careful
    distinction made between the mistakenly requiring as portable things that
    are non-portable on one hand, and foolishly prohibiting things that are
    not portable.

    The last paragraph in the introduction to the Instance Structure Protocol
    section is an example of this.

I believe that what you are saying is that it should be legal for a
specific implementation to define its own mechanisms for extending the
unerlying type system.  I agree.  I just don't think we can add to
Common Lisp something that gives users that power since it also gives
them the power to destroy the entire type system.
-------