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?

> 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.

> 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.

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