CALL-NEXT-METHOD Winter Solstice present

[kempf%hplabsz@hplabs.HP.COM]

Here we go again.

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. 

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

		jak