method-lambda and apply-method-lambda

[Gregor.pa@Xerox.COM]

    Date: Mon, 11 Apr 88 17:09 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    Patrick wanted the implementation-dependent calling sequence for method
    functions to be under meta-object control, which is why he proposed
    make-method-function to be generic.  

I should have noticed this before, unfortunately it didn't jump out at
me till over this weekend though.  In thinking about this even further,
I have concluded that the basic idea of having make-method-function and
apply-method be generic functions is flawed.  This message tries to
explore the reasoning behind this conclusion.

The basic conclusion is that the abstraction which Patrick and David's
proposal (the proposal) was trying to provide is inappropriate.  It is
trying to place an abstraction barrier between the method lookup
mechanism and the method invocation mechanism, and it turns out it isn't
a good idea to put an abstraction barrier there.

Lets start by looking carefully at the abstraction the proposal is
trying to provide.  It is trying to prevent the generic function's
method lookup mechanism from having to know the calling sequence of the
actual methods.  We might have thought that it was trying to protect the
actual generic function from having to know the calling sequence of the
method, but the fact that make-method-function takes the generic
function as its first argument shows that that isn't true.

Now we have to decide whether it makes sense for the actual method
calling sequence to be isolated from the generic function's method
lookup mechanism.  I will argue that it doesn't.

The basic reason is that the method lookup mechanism and the method
calling sequence `want' to be intimately connected.  For example, the
method lookup mechanism is supremely qualified to be looking up the
next-method-info; but in the abstraction presented by the proposal, the
actual method calling sequence must do that lookup itself.  It isn't
clear how one could implement a high performance method lookup and
invocation mechanism which also had to pass special information using
this protocol.

Now lets look at the case where one wants to have a different kind of
method on a generic function, where that different kind of method has a
different calling sequence.  In the proposal, if the different kind of
method has a different calling sequence, the class of the generic
function will have to be different (make-method-function takes the
generic function as its only specializable argument).  

Using the mop as written up (sort of) and implemented in PCL, the
generic function would also have to have a special class, and the method
lookup and invocation code would both be specialized by specializing the
single generic function compute-discriminator-code.  As mentioned two
paragraphs above, this is likely to have higher performance as well.

I think that the way to think about this is to acknowledge that generic
functions must understand the calling needs of their methods.  This
seems quite reasonable since they must already understand when to call
their methods.  In order to have methods which have special calling
needs, one must have a special class of generic function which
understands their calling needs.  Understanding their calling needs can
be thought of as part of the contract which the generic function entered
into when it agreed to have the method as one of its methods.

It could be argued that my argument is based on the existing arguments
to make-method-function and apply-method; that by changing the proposal
so that those generic functions accepted only the method as arguments,
it would be possible to specialize only the method to have a special
calling sequence.  This may be true, but the real point of my argument
is that this isn't a good architecture because it separates the method
lookup mechanism from the method invocation mechanism in an unatural
way.  In addition, the proposal has some other problems which I began to
surface in my last message.
-------