[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Moon's comments

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. 

The definition of superclass should really read:

    We will say that a class
    $C\sub{n}$ is a {\bit superclass\/} of a class $C\sub{1}$ if there
    exists a series of classes $C\sub{2},\ldots,C\sub{n-1}$ such that
    $C\sub{i+1}$ is a direct superclass of $C\sub{i}$, for $1 \leq i<n$.


    We will say that a class
    Cn is a *superclass* of a class C1 if there
    exists a series of classes C2,...,Cn-1 such that
    Ci+1 is a direct superclass of Ci, for 1<=i<n.

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.

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. It also gives the readers something
to hang onto that they already understand - lattices. 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.

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

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