On 2024-12-15 10:40 +0100, Marc Nieper-Wißkirchen wrote:
> > Thanks. I may simply add a note that the last expression in a
> > ‘define-restartable’ body may not be in tail position—assuming Marc or
> > I don’t find a better solution.
>
> I hacked Chez Scheme and proved by implementation that it is possible
> to guarantee that the last expression in with-exception-handler and in
> guard, respectively, is in tail position. It would therefore be
> feasible if SRFI 255 asks implementers to make sure the last
> expression of define-restartable is also in tail position.

That's acceptable. This would definitely be a RECOMMENDED feature,
however, since it seems to be impossible to implement in R[67]RS
Scheme.

> However, there is still a flaw. Even though the call stack won't grow
> with such a guarantee, the handler stack will grow. This is directly
> connected to the usability issue I mentioned in some other post. A
> recursion of depth 1000 would produce 1000 stacked restarters. We have
> to fix this in a practically and theoretically appealing sense. (It
> may help that one can detect tail positions with (immediate)
> continuation marks; see SRFI 226).

Yes, I've been looking into this since you mentioned it. I don't want
to depend on SRFI 226 just to get 'define-restartable' right, but it
would be nice if we could avoid this handler-stack growth.

* * *

As far as I can tell none of these issues are relevant to 'restartable'.
If you want a restartable tail-looping procedure, it's easy to
write with 'restartable' and a "let loop". Are we positive that
'define-restartable' is necessary?