Moon's comments on Draft 11

[Jon L White <jonl@lucid.com>]

[Preview of this msg.  Much of it relates to specific points brought up
 by you (Moon) in your cited message; but a few comments apply directly 
 to the mop proposal:
  (1) METHOD-FUNCTION is an ill-considered concept, for reasons having
      nothing to do with the optimized implementations that elide it
      for STANDARD-ACCESSOR-METHOD's; see comments below on "next methods"
      context and APPLY-METHOD.
  (2) Allow GENERIC-FUNCTION to be a "built in" class; i.e., do not do 
      anything that would require it to be of the same metaclass as 
      STANDARD-GENERIC-FUNCTION.
  (3) Users are telling us that extensible slot-option parsing and
      processing is a requirement for them; let's look at Cypher's
      proposal sent out a few days ago.
  (4) Avoid the compile-file environment issue; pass the buck from 
      the MOP realm into the compiler realm.
  (5) FUNCALLABLE is still too "cutsy" a syllable to be incorporated 
      into serious names.  It's acceptable only because it isn't used.
]
  

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"?

Although Lucid's 4.0 release supports the declarations "slot", it
probably doesn't do anything with it.  The next release, however, is
making serious use of that information for a wide-variety of optimizations.



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

The array of these metaclasses in Lucid's CLOS is that a "slotted 
mixin" is mixed with the built-in class FUNCTION to get a class
STANDARD-FUNCTION-OBJECT of metaclass STANDARD-FUNCTION-CLASS
-- i.e., functions which submit to some sort of SLOT-VALUE protocol.
By the bye, I'm using the term "slotted mixin" conceptually here
rather than referring to an actual superclass; in the case at hand,
the "mixin" is provided by a shift in metaclass rather than by
an additional superclass [and in fact the slotted capability is
adequately lifted into the metaclass realm by virtue of 
SLOT-VALUE-ABUSING-CLASS.]

STANDARD-FUNCTION-CLASS and its company more than cover the notion
of FUNCALLABLE-<mumbles>.  [Lucid's CLOS supports the latter only
for compatibility -- but there is currently little utility to it.]
However, if we view the "GENERIC" mixin as submitting to an ADD-METHOD 
protocol, then I'm beginning to agree with you that GENERIC-FUNCTION 
shouldn't be of metaclass STANDARD-FUNCTION-CLASS (or FUNCALLABLE-
STANDARD-CLASS) because the "generic mixin" by itself needn't require 
the full SLOT-VALUE protocol.  The easy way out for Lucid might be 
simply to tag GENERIC-FUNCTION as of metaclass BUILT-IN-CLASS [there 
is surely no requirement for the superclasses  of STANDARD-GENERIC-
FUNCTION to be all of the same metaclass.]



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.  Now, the fact that three implementations
do not in fact support a FUNCTION slot (in the "usual" way) for
STANDARD-ACCESSOR-METHOD -- Symbolics, Lucid, and TI -- suggests that
this concept isn't well thought out.  It does not, to me at least,
suggest that STANDARD-ACCESSOR-METHOD is poorly modularized as a
subclass (or extension) of STANDARD-METHOD.  The reason why I say
"to me" is that Lucid's upcoming versions of CLOS will have trouble
supporting the METHOD-FUNCTION concept for just about any methods; the
difficulty will not be limited to just the subset of accessor methods.

To drive the point home even more forcefully, what is the meaning of
METHOD-FUNCTION for standard, primary methods that use CALL-NEXT-METHOD?
Where is the "next methods" context?  what is the meaning of a "function"
for these methods without such context?  Recall how in mid 1989, Lucid
had to supply APPLY-METHOD which works a bit like APPLY, except that
it has an additional required argument for the "next methods" context.



re: [extensible slot-option processing]  Cyphers had a hairier proposal
    that allowed the class and slot options to interact, but since that isn't
    necessary to implement the built-in options I would leave out the hair.

I rather liked Scott's proposal, but because of it's detail, I haven't
been able study it well enough for a deeper reply.



re: I think ... the MOP should not pretend to make it unnecessary for 
    extension writers to coordinate with each other.  That's really not a 
    CLOS issue anyway, it's really a programming methodology issue, how do 
    you write programs that are good citizens of the shared Lisp world, and 
    should be addressed at that level.

I couldn't agree more.  Additionally, I would categorize the overconcern
with "compilation environments" for DEFCLASS etc. as similar in nature.
These "cross compilation" issues should not be confused with the MOP, nor
with anything particularly CLOS'y;  they should only be addressed in
detail, *** if addressed at all ***, in the context of a complete solution
for compile-time definitions such as DEFMACRO, DEFSTRUCT, as well as
a compile-time relativization of the package system and *FEATURES* list.


re: If the MOP can't figure out how to deal with the
    compile-file environment issue, it shouldn't say anything about it at all,
    not say something that will have to be repudiated later.

Hear, hear!!



-- JonL --