Re: Question about call-next-method

On 17 Nov 2025, at 17:34, Edward Kiser <[email protected]> wrote:
> 
> 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.

Whether it's heap or stack is an implementation detail.  What isn't is that, given

(defmethod foo (x)
  `(least-specific ,x))

(defmethod foo ((x number))
  `(number ,x ,(call-next-method)))

(defmethod foo ((x integer))
  #'call-next-method)

Then (foo t) returns (least-specific t), (foo 1.0) returns (number 1.0 (least-specific 1.0)) and importantly (funcall (foo 1)) returns (number 1 (least-specific 1)), and (funcall (foo 1) 'a) is an error (which may not be detected by the implementation).

Nothing says what happens if you do, say

(defvar *c* (foo 1))
(defmethod foo (x)
  x)
(funcall *c*)

But I would certainly expect that implementations are using method objects not specifiers for them, that those method objects do not get mutated, and so it will probably return the same result as above (this, in fact, is what both LW and SBCL do).

--tim

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