call-method proposal prime prime

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 11 Jan 88 21:18 PST
    From: Gregor.pa@Xerox.COM

    I spent some time thinking about how to solve the problem with
    make-method-call and concluded that make-method-call was a really
    complex little bugger.  I have come up with a mechanism I believe is
    simpler, 

This is pretty similar to a mechanism we rejected a year or so ago, which
is where MAKE-METHOD-CALL came from.  However, I think we made a mistake
back then, and I'm happy with your proposed mechanism, except for a couple
of details I'll note below.

We're running low on time to decide to adopt this and update the
documentation accordingly; can we make a quick decision?  I guess I
can volunteer to help with the rewriting of existing text, if needed.

    on first examination it appears to be missing the single method
    optimization but I believe that can be fixed quite easily.

The technique that MAKE-METHOD-CALL used can't work here.  We simply
have to decide whether it's the responsibility of the method-combination
function or of programs that analyze effective-method forms to know that
AND with one subform can be optimized.  They also have to know about
PROGN, MULTIPLE-VALUE-PROG1, etc.  Either way will work and is easy
enough to do.  In Flavors it's the responsibility of the analyzing
programs rather than the synthesizing programs, so that's my suggestion.
Either way, the CLOS specification must be explicit about this.

    This proposal uses two lexical macros, CALL-METHOD and EFFECTIVE-METHOD.
    These macros are lexically bound within the scope of an effective method
    body.  That means that the body of define-method-combination is allowed
    to return code that uses these macros.  Code walkers can understand
    these macros quite easily, I believe their semantics is also easier for
    programmers to understand.

     - call-method accepts two required arguments.  The method to
       call is the first argument.  The next methods accesible from
       that method is the second argument.

This doesn't distinguish between "no next method" and "call-next-method
not allowed."  MAKE-METHOD-CALL made that distinction.  If we need to
make that distinction, then I suggest one required argument and one
keyword argument, :NEXT-METHODS.  I don't think the Symbolics
implementation will need that distinction, but I don't know about others.

    Here are implementations of standard and and method combination written
    using this mechanism.

They look right except for one or two comma errors.  They are awfully
verbose, but I think I agree that in this particular case it's better to
be more verbose than to have a more obscure primitive for people to
learn.  Much of the verbosity is caused by the expressive poverty of
Common Lisp, not by your two macros themselves.  Fortunately, the short
form of define-method-combination eliminates the need for most people to
deal with the verbosity.

For fun:

(defun make-method-call (methods &key (operator 'progn)
				      (identity-with-one-argument
					(eq operator 'progn)))
  (unless (listp methods)
    (setq methods (list methods)))
  (let ((forms (mapcar #'(lambda (method)
			    (if (listp method)
				method
				`(call-method ,method ())))
			methods))
	(methods (mapcar #'(lambda (method)
			     (if (listp method)
				 `(effective-method ,method)
				 method))
			 methods)))
    (cond ((eq operator ':call-next-method)
	   (and methods `(method-call ,(first methods) ,(rest methods))))
	  ((and identity-with-one-argument (= (length methods) 1))
	   (first forms))
	  (t `(,operator ,@forms)))))

That wasn't so bad, was it?  In fact it's the same number of lines
as your new definition of standard method combination.