Am Mi., 18. Dez. 2024 um 00:44 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2024-12-15 17:50 -0500, Wolfgang Corcoran-Mathe wrote:
> > > 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.
>
> After a little more thought, I wanted to reiterate the problem I see
> with these semantics. We can remove the original condition except when
> it satisfies ‘restarter?’. In that case, all of its simple restarter
> conditions must be extracted and re-composed with the new restarters.
>
> This seems like an awkward special case.

How can this happen? As soon as the error condition is removed by a
handler, replacing it with a restarter condition, no further code that
adds restarters would be triggered, wouldn't it? Restarters are added
only in reply to certain conditions.

In any case, to proceed, to make sure that we are not going in
circles, and to have a model that will work in practice, we won't get
out of taking a real, non-trivial program and adding restarter
functionality to it. We then have to discuss this real use case and
benchmark the different models against that. Single toy examples like
"safe-/" are of no real help.

Do you have any idea of what non-trivial program we could take?
Preferably, it is one that is already using the R6RS condition system.

Marc