Re: The extent of CALL-NEXT-METHOD (a retraction)

[kempf%hplabsz@hplabs.HP.COM]

> Suppose we pick the `dynamic' extent.  Suppose that you've got a piece
> of code in some method that includes an FLET'd function and suppose
> further the method returns said function as its value.  This is fine, it
> should work, we've all probably done something like it a dozen times.
> However, if you've got a call to CALL-NEXT-METHOD inside that FLET'd
> function, then it doesn't work, something awful happens, we'll all get
> bit by it a dozen times and curse our short-sightedness.

I didn't buy this argument when I first heard it, and I don't buy it
now.

FLET and CALL-NEXT-METHOD are two different things. The definition of
a locally defined function must be lexically visible inside the definition
of FLET. That is, after all, the function of FLET. Thus, if the lexically
defined function is thrown out of the scope of the FLET, arrangement for 
calculation of a closure over the lexical environment can be made at compile 
time. The definition of CALL-NEXT-METHOD, on the other hand, is not lexically 
precisely determined at all. Within a particular lexical scope, 
CALL-NEXT-METHOD is defined to call the "next" method. Precisely what the 
"next" method is will be determined by the parameters of the generic 
function invocation, during the effective method calculation. In general, 
these can only be determined at run time, thus the definition of 
CALL-NEXT-METHOD is determined dynamically, and the compiler cannot form a 
closure if the CALL-NEXT-METHOD leaks out of scope. In specific instances
it may be possible to optimize out the run time calculation, but that
should not be of concern in specifying CALL-NEXT-METHOD does.

So, for CALL-NEXT-METHOD to become indefinite in extent, Common Lisp needs the
addition of dynamic closures. Other languages (and some extensions of
Common Lisp) have these-they're called "coroutines" or "lightweight processes".
These take a closure over varying aspects of the dynamic state of the
program. In the case of CALL-NEXT-METHOD, the amount of state which would
need to be saved may not be as much as in the case of a coroutine, but
the principle is the same.

Since this would be the only case of taking a dynamic closure in Common
Lisp, I think we should stick with dynamic extent.

		jak