Re: Method Combination Proposal

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

    I don't understand this reference to environment information. 
    I have never proposed any special programming environment
    facilities here, other than the :description thing to control
    printed representation. You're probably referring to my insistence
    that macros that don't check their arguments, but just ignore
    anything they don't recognize, are bad; I think this is a language
    issue, not an environment issue.

Yes the :description is an environmental issue, and when error control
is done is environmental.  I don't object to a macro checking its
arguments.  It was the checking of methods that are not found that is at
issue (see next paragraph).

    If I was going to do those programming environment facilities,
    I would try to do them by calling the method-combination function
    and seeing what happens, rather than by adding a new syntax to be
    used in the define-method-combination specifically to convey that
    information.  This is similar to the suggestion that the best way
    to find out what methods are actually called is to call the
    method-combination function and analyze the Lisp form it returns,
    rather than adding a new syntax for it to return a list of methods.

I don't understand how this helps in finding unacceptable methods (with
bad method qualifiers).  There can be any number of reasons (e.g.
shadowing with no call-next-method) why the result of a method
combination does not include some applicable methods.  So the result
cannot be what is checked.  It must then be some use of the selection of
methods that is used.  This is not specified (or only implicitly) by the
template language (and by FIND-METHODS). 

    Looking back over the old discussion, the motivation
    for the find-methods scheme was stated to be simplicity...
Yes, and I haired it up (sorry).  But, I think the language for
FIND-METHODS is an independent issue from whether FIND-METHODS should be
used for specifying subsets of methods or only the template language.
The real issue I believe is whether FIND-METHODS can only be used in a
define-method-combination body (in which case probably the template
language is as good as having the form) or whether there can be
sub-functions that use it;  clearly they cannot have the template
language.  I prefer having subfunctions have the same capabiities as
forms in the main body.

    (define-method-combination mine ()
      ((methods (*)))
      (grovel-my-method-combination #'make-method-call methods))
I found this very clever.  However, I prefer to have the auxiliary
information in the metaobjects for the reasons you give.  

With respect to the method-selection process, I was embarrased to hear
an argument I always use thrown back at me 
   "this would be done in Lisp instead of a special embedded language")
However, doesn't this put all the error checking in Lisp, even for the
simple cases.  I was proposing a simple error checking template language
with :qualifier-set.  Or, perhaps I just missed the dual purpose of the
method-group specifiers, to select AND error check the set of applicable
methods.

    Are you saying that in place of the qualifier patterns one
    could put the name of a predicate, in cases where the simple
    pattern match language wasn't strong enough?  That seems like a
    good idea. 

If we go with method-group specifiers, that is what I meant.  The
predicate gets as an argument the list of all methods not yet selected
in the generic-function, and returns a subset.

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

    I'd like to understand why.

Four reasons:
1) It hairs up the syntax of both define-method-combination and
defgeneric-options
2) With no good simple example of its use, its utility is much in doubt
in my mind
3) In thinking about defining the arguments to the methods in the
meta-object protocol (e.g. compute-effective-method) I don't want to
have extra arguments sometimes.
4) Without this argument list, there is no need for a simple form of
DEFINE-METHOD-COMBINATION since the one form is simple enough.  LEAN
proposal.   

If the method combination arguments are constants for the generic
function, then a specialized generic function with such state is
sufficient.  It does imply though that some mechanism must be found for
the user to get access to the generic-function in the body of
define-method-combination.  You said you had one you liked in Flavors --
what is it.

Do we want to hair up defgeneric-options to allow extra state to be
specified?  For example, one option of defgeneric-options could be
  (:slots slot-name-1 slot-value1 ...)
I find this preferable since it extends a much more general facility to
the user.

        In addition, I think the body of the method combination
        should have access to the generic function in question.  It
        can't get it from the methods since methods can be on more than
        one generic function. 

    I don't think that has been agreed to.  It seems to be simpler
    to allow sharing of method-functions, but not sharing of
    method-objects.

After some more thought on this issue, I can't find a good case against
it.  The form of argument against should be that one wants to change
some part of a method (say its function) and have this effect seen in
two generic functions.  I cannot think of a plausible scenario.  

Does this solve the access to the generic-function for
method-combination?  Only if in the place where the generic function is
required there is a guarantee that a method is available.  Is that
always possible?

        PROCLAIM-IDENTITY-WITH-ONE-ARGUMENT.   I don't see that
        this is an appropriate mechanism for dealing  with this
        optimization.  It may just be the name which is upsetting me, I
        am not sure yet.

    The other way to deal with this is to make it a keyword
    argument to make-method-call, which defaults to (eq operator
    'progn).  I would be happy with that; in fact I think it's what I
    proposed originally, but when we discussed this in Menlo Park, the
    change to PROCLAIM-IDENTITY-WITH-ONE-ARGUMENT was made (I forget
    who proposed it and what the arguments were). Note that the simple
    form of DEFINE-METHOD-COMBINATION would need this keyword argument
    too.
The objections to the keyword were
1) it was an extra keyword
2)  this information was something that was useful in more than this
context. Other method-combination types and other program constructing
programs can use the same information. Can we push this problem into the
COMPILER group for CommonLisp, and assume that they will propose
something like this?  It seems inappropriate for the object standard.

 
    To my way of thinking, the syntax of DEFINE-METHOD-COMBINATION
    is similar to the syntax of DEFMACRO and DEFSETF.  By the way,
    Flavors' DEFINE-METHOD-COMBINATION doesn't allow doc-strings.

Should we leave this out and allow this to be something beat back in by
the committee if necessary (Gives them a chance to piss on something).

  danny