The "restartable" form is to enable users to replace procedure
arguments in case of inadequate arguments delivered to a procedure.
The condition type for the latter exception is the assertion
violation.  Thus, it is out of the scope of the original idea of the
"restartable" form to consider other condition types.

This does not preclude the addition of other convenience syntax or
procedures handling other condition types in a tailored fashion.

Am Sa., 26. Okt. 2024 um 18:25 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Daphne,
>
> On 2024-10-24 21:04 +0200, Daphne Preston-Kendal wrote:
> > Why is the use of restarters limited to assertion violations?
>
> Only the restarters installed by the ‘restartable’ forms are currently
> restricted to handling assertion violations, because we conceived them
> as allowing the user to retry application with new arguments. There
> is, however, no reason that I can see for limiting them to &assertion
> conditions. ‘serious-condition?’ seems like a good default criterion
> to me, whether or not we end up allowing restarters to select which
> condition types to restart.
>
> ‘restarter-guard’ says nothing about the type of the triggering
> exception’s condition.
>
> The broader question (noted in the Issues) is whether it’s useful for
> a restarter to handle only certain conditions. I tend to think it is,
> but it may be tricky to work this feature into the SRFI 255 syntax.
>
> Regards,
>
> Wolf
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>