[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Moon's comments on Draft 11
- To: Moon@stony-brook.scrc.symbolics.COM
- Subject: Moon's comments on Draft 11
- From: Jon L White <jonl@lucid.com>
- Date: Wed, 31 Oct 1990 20:30:52 PST
- Cc: mop@arisia.Xerox.COM
- In-reply-to: "Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 31 Oct 1990 13:25:00 PST <19901031212511.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.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 --