Re: CALL-NEXT-METHOD Winter Solstice present

[Danny Bobrow <Bobrow.pa@Xerox.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.

This paragraph is taken out of context.  The "next" method is always the same
(defined in the purpose section of the writeup).  There is a list of methods
determined by the initial arguments to the combined method.  The next method is
determined by the order of methods in this list  (ordered from most to least
specific).  The next method is always the method in the list after the method
containing the call to call-next-method.

The intent of the paragraph above is to indicate that if arguments are provided
to call-next-method, the list of applicable methods, and order of specificity
must be the same as the original list.  This preserves the semantics of the
call.  The next method after the one containing the call to call-next-method in
the original list of applicable methods will be identical to one determined the
same way from a newly computed list.  NOTE call-next-method never can call a
method earlier on that list.

    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. 

Wrong.  It will be M(2).  Remember the rule is the same as it was earlier.

    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? 

YES.  It is just this case that the paragraph in question was trying to outlaw.