Re: Method Combination Proposal

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

Moon says:
    Looking back over the old discussion, the motivation for the
    find-methods scheme was stated to be simplicity, but in each
    version it gets more and more complicated.  I don't think it really
    achieves its goal.  Allow me to offer a few other criticisms,
    briefly:  The :qualifier-set option duplicates the information in
    the arguments to find-methods, with a different syntax, and with a
    different expressive power (unless one resorts to the escape to a
    predicate function).
But it is the escape that I expect to use, say, for allowing one to
specify for example, that a qualifier is a real (realp) where one uses
the numeric value to order the methods.  Or to specify a qualifier is
any single symbol used as a name.   


    ; this duplicate information will be highly error-prone.  
One answer is to add a new possible value, :explicit, for
:qualifier-set.  In this case, all  explicit calls to find-method will
be examined to determine allowable methods.

    The :qualifier-set syntax doesn't seem to allow a way
    to say anything about unqualified methods and doesn't seem to have
    the flexibility to deal with methods with more than one qualifier. 
    The examples are hard to understand since the :qualifier-set syntax
    used in the :and example is not the same as the syntax described
    earlier, and because the backquotes and commas are messed up.
I would be willing to look further at the language for :qualifier-set.
It was there to answer the stated needs for environment information, and
I didn't give it enough thought.

Moon says:
    The first part defines the meaning of the method qualifiers,
    while the second part defines how the methods are glued together. 
    It's important that the definition of the method qualifiers is all
    in one place, and I think it's important not to mix it up with
    other stuff.

The question is whether it is there at point of use.  Why isn't it
better to separate out environmental and programmatic concerns? 
 
    A survey of Symbolics object-oriented code shows that the form
    of standard method combination with the primary methods in
    most-specific-last order is not needed, so the standard method
    combination does not need to take any arguments (another
    simplification relative to my earlier proposals).  The same survey
    showed that most-specific-last order is quite useful with some
    kinds of method combination that invoke all the methods (rather
    than shadowing), specifically progn, list, append, and, and or
    (this list is in decreasing order of popularity).  The survey also
    uncovered a user-defined method combination type that takes &key
    arguments, hence my proposal still includes arguments in the
    :METHOD-COMBINATION option to DEFGENERIC-OPTIONS

You do not show this one example, and I strongly prefer not having
arguments for this form.  

    A list of method-group specifiers follows. 

I assume by this you mean the item noted by:
  ({(variable {qualifier-pattern}+ {keyword argument}*)}*)

Are the qualifier-patterns all lists or NIL, and hence distinguished
from the keywords?  The :ORDER keyword seems weak at best.

I don't see any way to specify to the environment that any single symbol
would be an appropriate qualifier, or that a realp was OK.  


    Declarations at the head of the body are positioned directly
    inside of bindings created by the lambda-list, and outside of the
    bindings of the method-group variables.


I don't understand this.  What does the declaration effect -- the
computation of the effective method form, or the compilation of that
form itself.


    If a doc-string is present, it documents the method-combination
    type.
Is this how we are going to do documentation.  Must we always provide
such strings?  Didn't someone else complain about this.

If I had to rank my objections, my strongest one is against the lambda
list.

Next is the restrictive nature of the qualifier language (I think the
escape to a predicate is crucial).

Finally, is the imposition of the idiom of putting the selection of
methods up front.  I could live with this if the selection language (or
at least the test for qualifiers) could be made stronger.  How about
making that form be
(variable find-method-filter &key :description :order)?


Somehow MAKE-METHOD-FROM-FORM got lost.  Isn't it needed in
method-combination standard around the multiple-value-prog2 form?
around is a list of methods, and the multiple-value-prog2 form is not.