Re: Question about call-next-method

I wouldn't generally write a program that would modify its own generic
functions while it was running. However, it's possible that I might
modify a generic function during debugging.

My conceptual model has been that a function consists of a blob of
machine code and an associated "stack frame format." When you
recompile a function, the compiler creates a new blob (which might
have a new stack frame format), resets the name to point to the new
blob, and then leaves the old blob to be garbage collected. But the
old blob cannot be garbage-collected until it is no longer being
used. So if the old version of the function has a call in progress,
there is still a live stack frame associated with the old blob, and
only the old blob would know how to unwind that stack frame, so the
stack frame should refer to its blob of code (directly, not by name),
and that should prevent the old blob from being garbage-collected
until all of its instances have returned.

The same general approach would work if you were storing call frames
on the heap instead of the stack.

If the compiler encounters multiple "lambda" forms it would have to
produce multiple blobs. Every time the lambda form runs, it captures
the variables and creates a new procedure which associates the
captured variables with the blob. So there can be multiple procedures
with the same blob of code but different variable captures.

I would expect CLOS to follow that "immutable blob" approach as
well. "Define-method-combination" creates a form which is presumably
passed to the compiler, so it would inherit the compiler's
behavior. So modifying the function would only affect new calls and
would not affect existing calls.

(Or at least that's the conceptual model I've been working with... it
has served me well so far...)

Even if CLOS does create immutable blobs, though, my original question
is one of whether the behavior of "call-next-method" is determined by
the heap or the stack. If it's the stack, the behavior will be popped
off when the generic function returns, and in that case the generic
function cannot expect to capture "call-next-method" for later.

I've read that some people have used CLOS to write Scheme
implementations, and so I thought CLOS implementers would have found
it useful to be able to define CLOS generic functions that could be
called from Scheme and therefore would have to adhere to the Scheme's
calling convention (e.g. continuation-passing style). Of course CPS
allows call/cc and all the trouble that implies.

On Sun, Nov 16, 2025 at 3:24 PM Bradford Miller <[email protected]> wrote:
>
> One of the things I specifically have in mind is the idea of “supercompilation” where you optimize a function for future use while running it based on monitoring its execution. Another idea is to compile (or finish compiling) a function after the arguments are known, which may eliminate or simplify much of the internal code. If that happens to affect internal loops, one can get a substantial reduction in constant factors that lead to significant run-time gains, even in the face of the overhead of running the compiler itself. (Of course, that would generally only apply to higher exponent polynomial complexity algorithms, NP-Hard functions, etc. depending on the actual size of the input).
>
> These, of course, are not new concepts (the REFAL language that first explored supercompilation dates to the 1970s). However, I’m not aware of anyone trying to apply these concepts to domain-specific applications of Lisp.
>
> On Nov 16, 2025, at 1:16 PM, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
>
> On 16 Nov 2025, at 17:30, Bradford Miller (as gorbag at icloud dot com) <[email protected]> wrote:
>
>
> One can already redefine common functions in the middle of a program and use them unless their calls were compiled
>
>
> Try to read what I wrote.  I'll quote it here:
>
> Still less should the behaviour of programs which might add, redefine or remove methods to a generic function while it is being called be defined.
>
>
> Do you see the bit I have now emphasized above?  So what you are asking or is not 'redefining functions and using them': it is redefining functions that are in the process of being called and then expecting that the new definition takes effect for that call.
>
> (Redefinition of ordinary functions is in fact allowed not 'unless they were compiled', but unless their callers were in the same file or they're declared inline.).
>
>

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html