Moon's Comments on RPG's Comments on Moon's Errata

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

    Date: 28 Feb 87  0012 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

[comments where I had nothing more to add omitted for brevity]

    Moon writes:

    ``I didn't think the phrase "where {\it parameter-specializer-name\/} is a
    parameter specializer name" added anything to understandability.''

    If a reader has gotten used to meta-syntactic items being linked to
    English phrases in a precise way, then failing to do that reduces
    understandability.

    How about this:

	  Each method has a {\bit specialized lambda-list}, which determines when
	  that method can be selected.  A specialized lambda-list is like an
	  ordinary lambda-list except that a {\bit specialized parameter} may occur
	  instead of the name of a parameter.  A specialized parameter is a list,
	  {\tt ({\it variable-name parameter-specializer-name\/})}, where {\it
	  parameter-specializer-name} is a parameter specializer name.  Every
	  parameter specializer name is a Common Lisp type specifier, but the only
	  Common Lisp type specifiers that are valid as parameter specializer names
	  are the following:

    This is Moon's rewrite with my pissant addition.

OK, I put that into the draft errata file I am maintaining.

    Moon correctly comments and asks:

    ``If this means that typep is to be extended to accept class objects, that is a
    reasonable extension to propose, however since it is mentioned nowhere else in
    the document and is not stated explicitly here, and was never discussed on the
    mailing list, I assumed that that was not the intention, and instead the
    problem was that the conversion from "parameter specializer" to "parameter
    specializer name" had not been carried out uniformly.  So which is it?  If
    typep is to accept class objects, we need an errata entry that makes that very
    explicit.''

    The class redefinition prose that Moon inserted into the document at some point
    in time requires either that the prose talking about TYPEP at this point in the
    document be removed or amended as I tried. I presumed that deleting content was
    incorrect, so I tried to fix up this prose to be consistent.  The offending
    statement is ``the function TYPEP can be used to determine whether an argument
    satisfies a parameter specializer.'' This statement is meant to reinforce the
    fact that the class system extends the CL type system. If this statement is to
    stand, TYPEP has to deal with class objects in addition to class names, because
    of the functional interface.

    More specifically, the issue is that MAKE-METHOD specifies class objects and
    possibly TYPEP should be used during generic function invocation to
    determine which methods are applicable. The class redefinition protocol
    requires that we be able to write methods that apply to classes that have been
    rendered obsolete (or nameless).

Of course there are other reasons as well to want anonymous classes.

    Here are the alternatives:

	    1. MAKE-METHOD takes class names; TYPEP operates on names and
	       type specifiers as usual (extended to classes); redefining
	       a class creates a stupid but predictable name for the ``old''
	       class (or we invent some funny notation to refer to obsolete
	       classes of various vintages).

	    2. MAKE-METHOD takes class objects; TYPEP is extended to class objects;
	       class redefinition renders the ``old'' class nameless.

	    3. We simplify the class redefinition protocol to eliminate
	       CLASS-CHANGED (this is the generic function that causes the
	       problem.

	    4. We can talk about how TYPEP can be used by the user to predict
	       which methods are applicable.

	    5. We can eliminate any statements about TYPEP.

    I think 3. is not easily acceptable, because Moon's class redefinition protocol
    is quite powerful (and suggestive to people trying to understand the system).
    Option 2. probably will piss off the Common Lisp crowd. Option 3. will piss
    me off. Option 4. is dumb. Option 5. requires some further changes to the
    document to provide the function that really decides satisfaction.

    Moon's further remarks on this point correctly indicate other problems that
    can be easily solved once we decide whether we really intend that TYPEP
    work on class objects.

After thinking this over, I think #2 is the only alternative that will fly.
Perhaps this will give bozos something to yell about at the X3J13 meeting.

The only real problem I have with this is the anomaly that in parameter
specializers classes are represented by the objects themselves but "individuals"
are represented by funny little lists with QUOTE in the CAR.  This doesn't
seem to generalize very well to other type-specifiers, should we want to
add them in the future.  Would it be better to introduce pseudo-class objects
(obeying a subset of the protocol of classes; in particular, you cannot
instantiate them) for these parameter specializers?  Or is it better to draw
a sharp boundary between real classes, which are full-scale objects, from
pseudo-class types, which are type-specifier lists?

Leaving that issue aside, I'd make the following amendments to the errata
to implement this suggestion.  This is a first draft and might need some
cleaning up before letting the general public see it.

1-13 First paragraph: Delete the last sentence.  Add a new paragraph at
the end of the page: "Every class that has a name has a corresponding
type with the same name as the class.  In addition, every class object
is a valid type specifier.  Thus (typep <object> <class>) is true if the
class of the given <object> is <class> itself or a subclass of <class>
and (subtypep <class1> <class2>) returns t t if <class1> is a subclass of
<class2> or they are the same class, and returns nil t otherwise."

1-19 seventh paragraph: Change to "This proposal requires that both
parameter specializers and parameter specializer names be Common Lisp
type specifiers."
[no substantive change here, this is just to avoid the possibility of
misinterpretation]

[no change any more to 1-19 eighth paragraph]

1-19 tenth paragraph: Change "parameter specializers are t" to
"parameter specializers are the class named t".

2-15 third paragraph: Add "A class object can be used directly as a
type-specifier.  Thus (typep <object> <class>) is true if the class of the
given <object> is <class> itself or a subclass of <class>."

2-54: Add pages for SUBTYPEP, TYPE-OF, and TYPEP, explaining that
SUBTYPEP and TYPEP are to be extended to accept class objects as
type specifiers, and explaining that TYPE-OF never returns a
class object [is this right?], with a cross-reference to CLASS-OF.

    I think I agreed with all of Moon's other errata. Moon: at some point (when we
    all agree on the list) you should mail your current errata list to me.

Will do.  Are you going to print up copies for the meeting or would you like
me to take care of that?