Re: Question about call-next-method

Hi Ed,

I sometimes write Scheme-like systems for myself… What is the connection you see between Scheme and CLOS Methods? Can you elucidate?



> On Nov 17, 2025, at 10:34, Edward Kiser (as edkiser at gmail dot com) <[email protected]> wrote:
> 
> 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


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