• To: Common-lisp-object-system@SAIL.STANFORD.EDU
• From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Date: Tue, 3 Mar 87 03:04 EST
• In-reply-to: The message of 28 Feb 87 03:12 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>

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

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.

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.

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?