Continuing comments on Draft 11

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

[First, some points of continuing interchage with your recent message;
 then two new comments on Draft 11. I will have more new comments at a
 later time, hopefully before Nov 15.]


re: Once it is fixed, method-function will be relevant to accessor
    methods as well as other methods.  That is, accessor methods will be
    required to return a method that does the right thing.  Most
    implementations, internally, probably won't ask for it though (unless of
    course they have reason to believe the user has mucked with it in some
    way).

In fact, Lucid's implementations return a dumb function that does do
a partially optimized SLOT-VALUE (mostly it does so in order to support
the METHOD-FUNCTION that came out of the moon/cyphers/jonl/franz(?) 
manifesto last March for a de-facto metaobject protocol).  Probably some 
other implementations do the same.  But what's the point of having it if, 
as you say, no implementation would really use it?  and if it is *only*
supported for compatibility?

In addition, as far as I know, no one has addressed the question of
methods requireing "next methods" context yet.


re: [Users requesting tailorable slot specification protocols]
    I would like to see the user comments in detail.  

Right.  Andreas sent some out recently (to which email list? I can't 
remember).  I have received some suggestions verbally from people who 
wanted to add an option which basically said "do type-checking on stores 
into this slot"; there's not much more to this except the need to
be able to parse a user-specified option, and to store the result in
a user-specified field of the slot-definition.  I vaguely remember
something in one of the CLOS workshop papers also, but . . . 



re: [compile-file environment issues] The current draft has less than 
    it used to. 

Now that you mention it, I see you're quite right!  It even has an
apologetic paragraph mentioning the "significant variance" among
implementations on the matter.  Good show.  Then I'm only echoing
Moon's suggestion to remove the couple of remaining fuzzy statements.


re: [FUNCALLABLE] I am reluctant to make simple name changes at this late ...

Yup.  Well, hey, we still have CAR and CDR despite FIRST and REST, no?


re: "STANDARD-" means the one that the user interface macros use by default.
    That is, what 88-002R says they do if you don't do any MOP stuff.

Well that's an interesting view.  But you can change the default for
DEFMETHOD by calling DEFGENERIC with a :method-class option, and that
step alone isn't MOP'y.  It's entirely another matter to say that
you can't create any other method class without MOP, or to say that
none of the specified metaobjects other than STANDARD-METHOD and
its subclasses will be suitable.

How about this view: ``STANDARD means "concrete"; otherwise "abstract"'',
with only a coule of exceptions (METHOD-COMBINATION and STRUCTURE-CLASS
come to mind as exceptions, but they are also exceptions to the
rule of ``"standard" means "default"'').

Probably it's only a coincidence that all three views mostly coincide
[the third being that ``"standard" means "slotted"''.]




Two point I want to bring up now, to get your feeling on them before
I say more in detail.

In an email discussion in the past, I recall discussing a fatal flaw 
in the design of ENSURE-GENERIC-FUNCTION -- namely the :lambda-list
argument doesn't carry enough information to be able to distinguish
the dual purposes of (a) a target of macroexpansion for DEFMETHOD and 
of (b) a target of macroexpansion for DEFGENERIC.  The current draft, 
under the DEFMETHOD section "Processing Method Bodies" punts the issue 
to ``The section "The Defgeneric Macro"''; but I can't find this section.
Did I overlook it somewhere, or is this an intentionalp lacuna?

There are six metaobject classes at or under SLOT-DEFINITION?  why?
Implementationally, there isn't any need to make a class distinction
between "direct" and "effective" -- this can be done by keeping
separate lists.   Admittedly, there is a need for a generic function
that goes through the step of taking collected direct definitions
and producing the effective definitions; but another class isn't needed.
The alternative would have at most two classes.



-- JonL --


P.S. Do we need a STANDARD-METHOD-COMBINATION?