Moon's comments on Draft 11

[Moon@STONY-BROOK.SCRC.Symbolics.COM]

In this message I am just answering questions that JonL asked me directly,
so lots of JonL's message is elided.

    Date: Wed, 31 Oct 1990 23:30 EST
    From: Jon L White <jonl@lucid.com>

    re: It would be unfortunate if there was a function named 
	GENERIC-FUNCTION-DECLARATIONS but it returned decl-specs rather than 
	declarations.   . . . 

    From the rest of your comments, I take it that the "unfortunate" thing
    would be in the assymetry of the names -- "DECLS-SPECS" as opposed
    to generic-function "DECLARATIONS"?

I would have said "inconsistency" rather than "assymetry", but yes.  I
certainly don't object to the existence of the function, I'm just trying
to make sure Common Lisp's terminology is consistent so there is some
hope of people being able to understand the definition of the language.

    re: However I question whether, as an abstract class, generic-function 
	should be committed to being a funcallable-standard-class.

    The "STANDARD" in "STANDARD-GENERIC-FUNCTION" might simply mean
    "Obeys a SLOT-VALUE protocol".  I don't particularly like that 
    interpretation, but that is the only consistent reading of the
    use of "STANDARD" I could come up with.  

I had always assumed that in CLOS, standard-this and standard-that means
"the class that is used by the programmer interface macros specified
in the standard."  I couldn't find this written down explicitly anywhere,
but it's a sensible reading of CLtL2 p.800.  I don't think it has anything
to do with SLOT-VALUE.

					     Thus the relation between
    STANDARD-GENERIC-FUNCTION and GENERIC-FUNCTION needn't be that
    of concrete to abstract class, but rather one simply of the
    former having the "slotted mixin" and the latter not having it.

I can't figure out what you're getting at here.  Are you claiming that
GENERIC-FUNCTION is not an abstract class, that is, are you claiming that
the MOP defines what it means to do (MAKE-INSTANCE 'GENERIC-FUNCTION ...)?
The first paragraph on p.3-11 of the pink book directly contradicts that.
And you can't be claiming that STANDARD-GENERIC-FUNCTION is not a
concrete class or not a subclass of GENERIC-FUNCTION.  Of course since
neither the MOP, nor I, nor you, have defined the terms "abstract class"
and "concrete class" we might not mean the same thing by them.  By
"abstract class" I mean a class that is not intended to be instantiated,
only to be subclasses, and by "concrete class" I mean any class that is
not abstract.  You and I probably do not disagree here, since we both
conclude that the metaclass of GENERIC-FUNCTION specified on p.3-10 is
questionable.

    re:   I question whether standard-accessor-method should inherit from
	  standard-method (although it does so in Symbolics CLOS); there is no 
	  place other than standard-method to attach behavior related to methods 
	  that have method-functions, yet accessor methods do not have 
	  method-functions (at least not in the same way that normal methods do), 
	  and thus should not be inheriting the behavior associated with them.  
	  The problem here is that standard-method is being used both as a 
	  concrete class (defmethod instantiates it) and as an abstract class 
	  (standard-accessor-method inherits from it); this is almost always a 
	  signal of incorrect modularity.  I believe standard-accessor-method 
	  should be a direct subclass of method.

    I'll have to disagree here (politely, if you please).  From the preceeding
    comments about a meaning for "STANDARD", then STANDARD-METHOD's simply
    submit to a SLOT-VALUE protocol -- the "STANDARD" in no way bears on the
    utility of a FUNCTION slot.  

The FUNCTION slot is a red herring and I'm sorry I led you in that direction.
Let me try again.  "The class STANDARD-METHOD is the default class of methods
that are defined by the forms [sic] DEFMETHOD, ..." (CLtL2 p.800, from 88-002R).
Page 3-10 of the pink book lists three subclasses of STANDARD-METHOD.  Nothing
in the revised pages of the pink book says what these three classes are for,
but from the names and from what we've seen in past MOPs we can assume that
DEFCLASS uses them in implementing the :READER, :WRITER, and :ACCESSOR slot
options.  Presumably it instantiates two of them and the third serves as
a common superclass to organize behavior common to readers and writers.
My objection is to STANDARD-METHOD being used for two distinct purposes:
as the default class of methods for DEFMETHOD, and as the superclass of
several other classes.  These purposes are distinct and should be served
by separate classes.  I see two ways to do that.  One is to make
STANDARD-ACCESSOR-METHOD a direct subclass of METHOD instead of a direct
subclass of STANDARD-METHOD; the other is to make a new class that is a
direct superclass of both STANDARD-METHOD and STANDARD-ACCESSOR-METHOD.
I support the former because it's simpler and I can't see a reason for
the latter, but I would certainly accept the latter if there is a reason
for it, for example if there is common behavior between the default
method class used by DEFMETHOD and the default method class used by
DEFCLASS that should be captured on a common superclass.  We can't make
the default class for DEFMETHOD be a new subclass of STANDARD-METHOD
because that would contradict 88-002R, otherwise this would be a third
way out.