[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


A problem we have never quite resolved is how to abstract out the
information about call-next-method (and slot optimization) that needs to
be passed to method functions.  I have said on several occaisons that I
would like for it to be possible to apply method functions to the
'natural' arguments; I would also like it to be possible to construct
method functions.  Moon has countered quite rightly that this makes it
difficult to implement call-next-method.  This message proposes a
solution to this problem and proposes some significant reduction in
some contentious parts of chapter 3.

Briefly I propose that we introduce a constructs called method-lambda
and method-apply.  In addition I propose that we eliminate the
defmethod parsing (and defclass parsing) parts of the mop.

method lambda is like lambda except that the functions it 'produces' are
designed to be called with method-apply.  The results of calling a
method lambda with ordinary apply are undefined.  There might also
have to be a method-function-p predicate.

method-apply is like apply, it takes the 'natural' arguments that
want to be passed to the method function.  It does anything else that
needs to be done to call the method-function properly.  I don't know
whether or not it wants to take a list of next methods, I suspect it
doesn't.  call-next-method inside of the called method-function would
just say there were no next methods.

Here is some sample code.

(defun trace-gf (gf)
  (let ((nargs (generic-function-required-arguments gf))
        (lambda-list (generic-function-congruent-lambda-list gf))
	(specializers (make-list nargs :initial-element (symbol-class 't)))
        (qualifiers '(:around))
        (function (compile () `(method-lambda ,lambda-list
				 (format *trace-output* "~&Hi there.")
    (add-method gf
		(make-instance 'standard-method
			       :lambda-list lambda-list
			       :specializers specializers
			       :qualifiers qualifiers
			       :function function))))

This code itself is kind of silly, but it shows why it must be possible
to construct a function that can be used as the function of a
standard-method.  Other obvious examples (like steppers) show why it
must be possible to call a function that was constructed by defmethod.

I propose that we eliminate the defmethod parsing stuff because this
provides a significant part of the functionality that was going after
and because the defmethod parsing stuff is one of the least well worked
out parts of the mop.  I do think we should be able to agree on
method-lambda, method-function-p and method-apply pretty quickly though.