CALL-NEXT-METHOD Winter Solstice present

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 24 Dec 87 17:37:45 MST
    From: kempf%hplabsz@hplabs.HP.COM

    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
	    programmer.

    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
    daemon methods).

    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
context.

    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
    an error? 

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.