Re: Continuing comments on Draft 11

[Gregor Kiczales <gregor@parc.xerox.com>]

Here is an outline of a proposal for dealing with passing in extra
information like next-methods to the bodies of methods when they are
excecuting.  This proposal is designed to allow methods body
specializations which don't require additional dynamic information, but
does not support method body specializations that do.  So, for example,
if we didn't already have the concept of next methods and
call-next-method, you couldn't implement it with this protocol.

I present this, using a naive implementation model.  Needless to say,
implementations can use the usual sorts of tricks to further optimize
this in the absence of any user meta-level incursions.

make-method-lambda takes a gf, method, lamba-expression, and environment
as arguments.  It returns a lambda expression which, when efunctuated,
produces a function whose lambda-list is is (args next-methods).  The
args is a list of the arguments to the generic function.  next-methods
is a list of the next methods to the function.

so, given a defmethod form like:

(defmethod foo (a b c)
  (bazola a b c))

the standard method on make-method-lambda would return a value something
like:

(lambda (args next-methods) 
  (apply #'(lambda (a b c) 
             (flet ((call-next-method ..)
                    (next-method-p () (not (null next-methods))))
               (bazola a b c)))
         args))


If the user wanted to define a new class of method that added a lexical
function binding FOO around the body they would define a method like:

(defmethod make-method-lambda ((gf standard-generic-function)
                               (method my-method-1)
                               lambda
                               environment)
  (call-next-method gf
                    method
                    `(,(car lambda) ,(cadr lambda)
		       `(flet ((foo ..)) ,(cddr lambda)))
                    environment))

(Note that this doesn't treat declarations properly.  We can either say,
look, its easy to get decls right in new Common Lisp, or we could split
the lambda argument up into three args, lambda-list declarations, and body.)

METHOD-FUNCTION, on a method, would return a function of two arguments
(a list of args and a list of next methods).  This is important to have
for things like user-built steppers.  The implementation-model would be
that impls would call METHOD-FUNCTION, but, as usual, they don't have to
call it if they know what they are going to get.  That is, there are no
relevant meta-level incursions.