I’m forwarding John’s message to the list. I think there was a
missing CC.

----- Forwarded message from John Cowan <xxxxxx@ccil.org> -----

Date: Fri, 13 Dec 2024 21:05:23 -0500
From: John Cowan <xxxxxx@ccil.org>
To: Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
Subject: Re: New draft (#8) and last call for comments on SRFI 255: Restarting
	conditions

We shouldn't remove something useful just because it's not tail recursive.
Fold-right isn't tail recursive, but when you need it you need it.

On Fri, Dec 13, 2024, 5:27 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
wrote:

> Marc,
>
> Thanks for your thoughts.
>
> On 2024-12-13 20:52 +0100, Marc Nieper-Wißkirchen wrote:
> > Related to this is that the examples of "with-current-interactor" can
> > be misleading. One may think that at every critical place, one needs
> > to wrap with "with-current-interactor".
>
> Good point. Since it’s just boilerplate, I think it can be removed from
> the examples.
>
> > A problem that hasn't occurred to me yet is that the original
> > condition that triggered the addition of a restarter should remove the
> > original condition from the compound. Semantically, adding a restarter
> > should mean that the condition is handled (unless the restarter with
> > tag "re-raise the condition" is invoked). If not, say, if an assertion
> > violation is raised, all procedure calls in the call stack that are
> > protected via "restartable" would present a restarter (even with the
> > same tag) to the user. In case of a deep recursion, this would also
> > make the interface unusable.
>
> As I see it, raising a restarter doesn’t mean the original condition
> has been handled, but that one possible way of handling it is being
> proposed. The condition is handled when the user chooses a restarter
> and ‘restart’ is invoked. Removing the original condition also makes
> it impossible to report anything about the triggering condition to the
> user, aside from whatever is included in the restarters themselves.
> All told, this leaves the user in the dark: “Something went wrong—no,
> we won’t tell you what, and everything’s fine now that you’re here.
> What do we do next?”
>
> > Then there is a serious problem I haven't thought about before:
> > "define-restartable" kills all proper tail calls; if a procedure
> > protected by "define-restartable" is part of a recursive algorithm, it
> > will never tail-call. This is bad; it should be safe to replace
> > "define" with "define-restartable" without changing the semantics. I
> > have to think of a solution.
>
> You’re right. This seems hard to solve. I will think about it some
> more, too, but I suspect we may have to remove ‘define-restartable’.
>
> with-exception-handler’s non-tail-position semantics also make it
> impossible to specify tail position for the body of a ‘restarter-guard’
> form, sadly.
>
> > I have one more question: Can you explain why the
> > restarter-condition-predicate could be helpful?
>
> Some restarters may only be relevant to certain situations. I had I/O
> conditions especially in mind here. A program that reads from a port
> might want to offer a restarter that changes port settings before
> retrying a read operation, for example. This would probably make sense
> only if a condition satsifying ‘io-read-error?’ or a similar predicate
> had been raised.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>

----- End forwarded message -----