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?
