[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: call-method proposal prime prime
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: call-method proposal prime prime
- From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
- Date: Fri, 15 Jan 88 09:45:38 CST
- In-reply-to: Msg of Thu, 14 Jan 88 22:40 EST from "David A. Moon" <Moon@scrc-stony-brook.arpa>
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.
I thought the synthesizing program (the method combination function) would be the
natural place for this optimization. I say that because the short form of
DEFINE-METHOD-COMBINATION has the optimization option, :identity-with-one-arg that
enables the method function to perform the optimization.
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.
Why can't we use an optional second argument instead of a keyword?, I don't think
that we want to allow extensions.
Besides these points, I am happy with Gregor's proposal. I don't think that
MAKE-METHOD-CALL will be used widely enough to justify its existence.