[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Method-lambda and apply-method-lambda
>>I don't think that method-lambda, as describe in 88-003 is good enough. It
>>captures the contract between a class of generic functions and a class of methods,
>>so it should be metaclass driven. You can imagine several contracts on a single
Why, precisely, do you think there need be any difference between a method
function and any other kind of function? I can understand this for
a generic function, since a generic function has slots, but a method
function has none. It seems to me that most of how a method function
differs is covered by additions to its lexical environment, and that
FUNCALL and APPLY should do.
I agree that in structure, a method function is like any other function. However
method functions are getting called with(in) an implementation dependent
environment that must be abstracted from the user. This is the motivation for
the encapsulation (method-lambda, apply-method-lambda) given in chapter 3. The
point of my earlier message is that this encapsulation should be metaclass
The things that may be contained in the environment are(among others):
Permutation vector(s), call-next-method list.
This environment is distinct from the lexical environment of a closure. That
does not prevent some implementation to code it as if it were a lexical
environment, but that's an implementation choice.