On 2024-12-15 17:15 -0500, Wolfgang Corcoran-Mathe wrote:
> > 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.

Sounds good to me.

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

I'm beginning to see your point. However, some components of the
condition (i.e. the restarters) must be included in the condition
raised by 'restarter-guard'. This is a little bit ugly in the
recursive case; instead of

    (apply condition con new-restarters),

'restarter-guard' must raise something like

    (apply condition
           (append new-restarters
                   (filter restarter? (simple-conditions con)))),

where new-restarters is the list of restarters installed by this
'restarter-guard', and con is the triggering condition.

There is also no guarantee that an arbitrary handler won't intervene
and do something surprising during the pending restart. But this is
probably an unavoidable risk of using the exception system to implement
restarts.

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

I agree. We can remove the condition predicate field.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>