Gabriel's comments

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

    Date: 25 Jan 87  1652 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Moon writes:

    ``Huh?  I can't figure out what, if anything, this is supposed to mean.''

    This was about a terse comment acncerning naming generic functions.  In a
    previous draft there were several sentences talking about the names of
    generic functions as if there were such things.

    ``The name of a generic function is in a certain package and can be...''

    ``Typically a generic-function object is stored as the function definition
    of the symbol that is the name of the generic function...''

    These two sentences gave the impression that generic functions are named
    in a way that functions are not. The sentence Moon objects to,

    ``The naming conventions for generic functions are precisely the same as
    those for ordinary Common Lisp functions,''

    is an attempt to eliminate that impression. 

Elsewhere in my comments I suggested saying very explicitly that generic
functions are named in the same way as regular functions, and describing
quite explicitly the way that defmethod and defgeneric-options call
symbol-function, so this can be folded into that.  We're agreeing with each
other, and we just need to wring out ambiguities of English.

    The definition of superclass should really read....

Your revised definition is good.

    Moon writes about ``classes at or above a given class'':

    ``Ugh!  Can't we find a more concise term for this?''

    It's not worse than ``less than or equal,'' which was the model for it.
    I, apparently, was the only person to try to think of a name, so someone
    else should propose one.

I've proposed one.  Several times.  Remember "component"?

    Moon writes:

    ``This whole paragraph doesn't make complete sense, because there is not
    -one- local precedence order; there is a separate local precedence order
    for each component class, and all of them are taken into account.''

    And then he proposes an alternate explanation. I think that breaking things
    down into a lattice with ordered direct superclasses makes understanding
    easier than clumping things together.

Either you didn't understand what I said or I didn't understand what you
just said.  I don't see that any concepts that ought to be separate
would be clumped together.  My suggestion would allow you to eliminate
the references to C-sub-l and speak only of C-sub-P (using the
terminology in the latest version of the file).  It also would not be
necessary to speak of the second and third partial order any more.  The
whole explanation would get simpler.  You'd be describing the same
program behavior with half as many words and concepts, so it would be
correspondingly easier for the reader.

    It also gives the readers something
    to hang onto that they already understand - lattices. 

I'm not sure that's a virtue, since the rules here are different from
the rules for lattices and intuition about lattices might be misleading.
However, the thought that giving readers a lattice to hang onto might
still be useful is why I suggested maybe using lattices as a heuristic.

							  Also, we don't have
    to think of a name for the class inheritance structure. The description of
    the computation has been clarified somewhat over what Moon has seen.

Actually I was reading your new version.  That allowed me to omit a lot of
comments addressed to problems in the previous version that you had already
corrected.

    Moon then comments on the ``flood of mathematics'' in the description of
    the CPL computation. The description of the CPL computation is meant to be
    precise. We are writing a specification, not a user's guide. Let the
    companies write user's guides. My own canvassing of readers showed that
    the explanation based on local rules - the explanation that was in
    CONCEPTS earlier and which I replaced with the current explanation - was
    not understandable by a range of people, including algorithms hackers.
    The most experienced algorithms hackers were not entirely sure that the
    rules provided a well-defined total ordering, nor did they completely
    believe that the algorithm would run in reasonable time.

I think I was the first to say that the previous explanation was not good.
Your replacement explanation is definitely better.  I am trying to improve
it further with my suggestions.

    I will need major convincing that a second explanation is needed. Perhaps
    we need to work on the current one to make it understandable to
    casual readers, but that is a separate affair. I will take a try at
    re-writing the computation description using the local precedence
    order definition Moon suggested.

Please note that I did not suggest adding a second explanation.  I
suggested eliminating unnecessary complexity from the current one (with
no thought of casual readers, incidentally), plus adding some motivation
(partly for casual readers, partly so the X3J13 committee will be able
to understand what we are presenting them with in a reasonable amount of
time).  In making a proposal, I believe that motivation for why things
are proposed to be a certain way is nearly as important as a precise
description of the particular way they are proposed to be.  This makes
it much easier to evaluate the proposal, and it makes implementors
likely to implement the proposal with fewer mistakes.

    Moon writes:

    ``I found the description of preorder treewalk virtually incomprehensible.``

    Gabriel collapses. I really, really find this hard to believe. Let's look
    at it:

    ``A preorder treewalk is defined in terms of the order in which classes
    are visited while performing a process called ``walking from a class.''
    The following is a recursive definition of walking from a class.  Let C be
    a class and let C1...Cn be its direct superclasses in the local precedence
    order.  Nodes are visited unless they have already been visited.  To walk
    from C, first C is visited, then we walk from C1, then we walk from C2,
    and so on until we finally walk from Cn.''

    I can write the program to do this from this description.  

So can I.  I don't see what that has to do with it.  It took me just as long
to understand the English as it would have taken to write and debug the program,
and I don't see why we can't do better than that.  If we can't, let's put the
program in the document and take out the English.

							       This description
    is about as closely copied from Knuth as it can be, given that we don't have
    trees and that the same classes can be encountered by different paths.