Re: Comments on define-restartable (was Re: New draft (#8) and last call for comments on SRFI 255: Restarting conditions)
Marc Nieper-WiÃkirchen 15 Dec 2024 09:40 UTC
Am Sa., 14. Dez. 2024 um 23:48 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2024-12-14 13:57 -0500, John Cowan wrote:
> > I don't disagree. But if the choice is between a non-TR implementation and
> > no implementation, I favor the first.
While implementations may not get it right but still be usable, the
specification itself should get it right. For example, Scheme has
proper tail calls and wouldn't be the same language if they were
removed; yet, implementations that cannot implement them fully can
still make sense.
As far as SRFI 255 goes, it has to get the semantics right and give a
hint how to implement it properly.
> 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.
Such a note would be evidence that our restarter model is still flawed.
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.
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).
Marc