method-lambda and apply-method-lambda

[Gregor.pa@Xerox.COM]

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

    There's something missing from your message.  Isn't the only reason
    make-method-function and apply-method were proposed (by you originally,
    Gregor) to allow users to interject code between the method lookup and
    the method invocation, for instance when tracing?  Otherwise there would
    be no need to standardize these little pieces of the implementation of
    generic functions when we don't standardize all the rest of it.

I believe that I originally proposed method-lambda and apply-method as
unspecializable interfaces to the standard kind of method.  I still (or
once again) believe that all we need is some sort of unspecializable
interface to the implementation specific calling sequence for standard
methods.  This will allow two things: 
						
1) users can generate method functions which can be used by the
   implementation's own method lookup and invocation code.
   (method-lambda or make-method-function)

2) users can call the implementations own method functions if they
   want to (usually for some sort of debugging or tracing purposes).
   (apply-method-function)

While I still like method lambda (for the reasons I stated in a previous
message), I am willing to accept your argument that:

    Right.  I agree that the two properties Gregor proposes sound important,
    but I believe that it is impossible to achieve those properties.  I think
    that the attempt to achieve those properties is why we've been having
    trouble converging here.  Giving up those properties will make the problem
    much easier, and I don't think it means giving up anything that matters.

and am willing to accept your suggestion that the criterion we should
shoot for are:

    I think the -only- assertions guaranteed about the value returned by
    MAKE-METHOD-FUNCTION should be:
    
     - COMPILE works on it
     - the FUNCTION special form works on it
     - it and the result of compiling it are members of the type FUNCTION
     - APPLY-METHOD works on it and on the result of compiling it
     - it and the result of compiling it can be used as the :method-function
       when creating or reinitializing a method meta-object

Which means I am proposing that have make-standard-method-function as
an unspecializable function whose result has the above properties and
apply-standard-method-function as an unspecializable function which can
be used to apply them.

I also think the next methods argument to apply-standard-method-function
should be a list since I don't see any real advantage to making an
abstraction for it.  Remember that in this scheme, it is clear that
apply-standard-method-function is not really the mechanism used by
standard method lookup.  Rather it is a hook which the standard lookup
mechanism provides for unpriveledged callers of the method functions.

    So I think the abstraction barrier isn't between method lookup and
    method invocation, but rather between those two mechanisms on the one
    hand and user-written code on the other.  But this only says why these
    two functions should exist, not whether they should be generic or
    not.

Right.

    I agree that the method lookup mechanism and the method invocation
    mechanism need to understand each other in detail.  What I don't
    understand is how that has any bearing on whether or not these two
    functions should be generic, i.e. whether or not there should exist
    more than one method invocation mechanism.  I guess I don't understand
    PCL's compute-discriminator-code generic function, since I don't
    understand how specializing that could affect what parameters the
    compiler makes a method-function accept.

The idea is not that specializing compute-discriminator-code can "affect
what parameters the compiler makes a method-function accept".  Rather,
the idea is that for a given method on compute-discriminator-code there
is a certain kind of method function (and corresponding calling
sequence) which is appropriate.  A given class of generic function
states (by having an appropriate method on add-method) whether or not it
is willing to contract with the calling sequence of a given class of
method's functions.  If there is such a method on add-method, it is a
declaration that the compute-discriminator-code method for that class
of generic function can handle that class of method.

    In conclusion, while I agree with all of your message that I understood,
    it doesn't seem to me to have any bearing on the issue it was supposed
    to be about.  Obviously I missed something big that you thought was
    there.

We have to find some way to converge on this soon.  My basic point is
that the genericity should be at the level of add-method and
compute-discriminator-code and that at the level of making method
functions and calling method functions the code should not be generic.

I am afraid I am just restating myself, but perhaps I have clarified
some part of what I was trying to say?
-------