[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
call-method proposal prime prime
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: call-method proposal prime prime
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 14 Jan 88 22:40 EST
- In-reply-to: <880111211858.6.GREGOR@SPIFF.parc.xerox.com>
Date: Mon, 11 Jan 88 21:18 PST
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
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.
(defun make-method-call (methods &key (operator 'progn)
(eq operator 'progn)))
(unless (listp methods)
(setq methods (list methods)))
(let ((forms (mapcar #'(lambda (method)
(if (listp method)
`(call-method ,method ())))
(methods (mapcar #'(lambda (method)
(if (listp method)
(cond ((eq operator ':call-next-method)
(and methods `(method-call ,(first methods) ,(rest methods))))
((and identity-with-one-argument (= (length methods) 1))
(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.