Forwarding Marc's reply to the list.

----- Forwarded message from Marc Nieper-Wißkirchen <xxxxxx@gmail.com> -----

Date: Sun, 15 Dec 2024 23:00:54 +0100
From: Marc Nieper-Wißkirchen <xxxxxx@gmail.com>
To: Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
Subject: Re: New draft (#8) and last call for comments on SRFI 255: Restarting conditions

Am So., 15. Dez. 2024 um 22:50 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2024-12-15 22:08 +0100, Marc Nieper-Wißkirchen wrote:
> > There should be an
> > option to abort a restarter, meaning to reraise the original condition
> > to handle it further up in the handler stack.
>
> That makes sense to me. Should 're-raise' be a recommended restarter
> tag?

This should probably be a default restarter tag that is automatically
added; there should probably also be a "raise-continuable" option.

> > The current model has the problem that handlers further up the handler
> > stack cannot know whether the condition they observed will eventually
> > have been handled or not.
>
> I'm not sure I know exactly what you mean, but this reminds me of
> the fundamental problem with SRFI 249's restarters, which didn't
> capture control context. SRFI 255's restarters do, but there is more
> context (like the complete handler stack and filesystem state) that
> they can't capture. If you are reading from a file and an up-stack
> handler deletes the file, then a 'retry' restarter added by the
> reading procedure will crash.
>
> I don't currently know how to solve this problem.

The problem is what I perceive as a flaw of the current system; as
long as there are restarters available, the condition must be hidden
from other handlers. A pending restart *is* a handled condition,
semantically.

>
> > Apart from that, a restarter is added by a handler; in your example,
> > the restarter would have only been added in case of an io-read-error?.
>
> How's that? It's true that the restarter would only be added to an I/O
> read condition, but this is because I've specified 'restarter-guard'
> to check the triggering condition against each restarter's condition
> predicate. Without those predicates, you would get all of the restarters
> installed with restarter-guard, regardless of the condition type.

That a predicate is checked by "restarter-guard" is perfectly fine; a
course predicate is typically okay because the context is known.
Later, the predicate is no longer of good use, so I think it should
not be part of the restarter condition.

Marc

>
> I agree that condition predicates are a bit coarse, but a more general
> mechanism for determining whether a given restarter is relevant would
> need much more context (see above).
>
> Regards,
>
> Wolf

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