[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CALL-NEXT-METHOD Winter Solstice present
Date: Thu, 24 Dec 87 17:37:45 MST
We redid the algebraic specification for CALL-NEXT-METHOD to include arguments,
as the current draft of the spec allows, and the wording of the spec seems
to allow too much latitude in the semantics. The current spec says this
(pg. 2-9 in my copy):
When CALL-NEXT-METHOD is called with arguments, the next method
is called with those arguments. When providing arguments to
CALL-NEXT-METHOD, the following rule must be satisfied or an
error is signaled: The ordered set of methods applicable for a
changed set of arguments for CALL-NEXT-METHOD must be the same
as the ordered set of applicable methods for the original
arguments to the generic function. Optimizations of the error
checking are possible, but they must be invisible to the
The problem is that there is no precise definition of what "next" method
means in this context.
Consider the following example. A generic function, GF is invoked with
the argument list AL. The computation of the effective method yields
the list of applicable methods ( M(0) M(1) M(2) M(3) M(4) ). For
simplicity's sake, say that they are all primary methods (i.e. no
Say that M(0) invokes CALL-NEXT-METHOD with no arguments, M(1) does
also, and M(2) invokes CALL-NEXT-METHOD with precisely the arguments
which it was passed. The sorted list of applicable methods won't
change, but the "next" method will be M(0), since it is the next
matching method on the list.
I think you misunderstand the description of CALL-NEXT-METHOD. Whether
or not arguments are supplied to it does not change what method it calls.
The next method is M(3) regardless of anything M(2) may do.
Evidently we need to change the documentation to say explicitly that
"next method" means the same thing in this context as in the other
Now say that M(2) invokes CALL-NEXT-METHOD with a list of arguments,
the classes of which match the parameter specializers for M(1). The
sorted list of applicable methods for this call is a truncated version
of that for the original invocation (the CDR, in fact). Would that be
It would signal an error. The documentation seems quite clear on this.
If not, then, again, the matching method would be one more
specialized rather than more general.
Neither of these cases are forbidden by the wording of the document.
We need a definition of "next" method, and I think a conservative
extension of the semantics in the nonargument case suggests that
the list of applicable methods in the execution envrionment (what
I mentioned at Boston) only include more general methods than the
currently executing one. Thus, CALL-NEXT-METHOD could only call
more general methods.
I prefer the definition that the documentation is intended to say now,
which is that CALL-NEXT-METHOD calls the same method regardless of
what arguments you give it, and the arguments you give it are not
allowed to change the applicable methods. That seems simpler than a
more relaxed definition that tries to state which cases of changing
the applicable methods are allowed and which aren't, and in what
circumstances CALL-NEXT-METHOD calls a different method from the
one it would normally call.