[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
method-lambda and apply-method-lambda
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).
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
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
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?