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

Re: method-lambda and apply-method-lambda

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