[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: method-lambda and apply-method-lambda
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: method-lambda and apply-method-lambda
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 20 Apr 88 22:48 EDT
- In-reply-to: <880414150957.6.GREGOR@SPIFF.parc.xerox.com>
I agree with what Gregor said in the referenced message, except
for two small points noted below. Does any of this affect chapters
1 and 2? It would only affect CALL-METHOD, and I don't think it does,
so we can defer completing the last details of this for a few days.
Date: Thu, 14 Apr 88 15:09 PDT
From: Gregor.pa@Xerox.COM
make-method-function (generic-function method lambda-list body)
This has to take a macroexpand-environment also. This sometimes needs
to do code analysis of the body, at least for some method calling
sequences, and it is impossible to do correct code analysis of a piece
of code without having a macroexpand-environment.
apply-method-function generic-function method function info &rest args
This is also a generic function. It tends to be specialied on its first
two arguments as well. For the case where generic-function and method
are both standard, the info argument is a list of the next methods.
I still believe that the representation of the info used for
call-next-method has to be abstract. CLOS should not dictate that it is
represented as a list. Note that I am not only saying that user-defined
method calling sequences should be able to use any representation they
want; I am also saying that CLOS should not dictate what representation
the standard method calling sequence uses. See my message of 8 April
for the two functions that have to be added to the system to abstract
this.