Standardizing the macroexpansion of make-method-call

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

    Date: Tue, 5 Jan 88 12:54 PST
    From: Gregor.pa@Xerox.COM

    ....we also need some facility
    which lets the user call a random function on the same arguments the
    generic function received.  This facility might be called
    MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a
    better name.  We have seen several examples of people who want a method
    combination type which performs some specific behavior as part of the
    combined method but that behavior needs access to the arguments to the
    generic function.

    Inventing this might even lead us out of the mess we have with
    make-method-call because it might force us to come up with a real
    abstraction for 'captured calls' and for 'access to the generic function
    arguments'.

    More on this later if I can think of anything, I sent this now hoping it
    might help someone else think of something.

I assume you decided we don't really need to do anything about this,
since it wasn't in your later message.  If we do, here's a suggestion.
In Flavors, we just put

  (:ARGLIST . lambda-list)

in front of the body of the define-method-combination, and parameter
variables in the lambda-list are bound to forms that can be inserted into
the effective-method to access the corresponding arguments to the generic
function (I guess they are gensyms or something).  Extra arguments to
the generic function can be ignored.

This seems simpler for the application you described than introducing a
function call.  Here's a simple example:

(define-method-combination progn-with-lock ()
	((methods ()))
  (:arglist object)
  `(unwind-protect
       (progn (lock (object-lock ,object))
	      ,@(mapcar #'(lambda (m) `(call-method ,m ()))
			methods))
     (unlock (object-lock ,object))))