On 2024-12-18 08:31 +0100, Marc Nieper-Wißkirchen wrote:
> Am Mi., 18. Dez. 2024 um 00:44 Uhr schrieb Wolfgang Corcoran-Mathe
> > 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.

You may be thinking of ‘restartable’, which only restarts assertion
violations. ‘restarter-guard’ installs restarters for arbitrary
conditions, so it may indeed have to add restarters to a restarter
condition:

    (restarter-guard (((return-four)
                       ""
                       condition?
                       4))
      (restarter-guard (((return-five)
                         ""
                         condition?
                         5))
        ...))

Here, the handler for the outer ‘restarter-guard’ will be passed a
restarter. If we adopt “remove the triggering condition” semantics,
only the ‘return-four’ restarter will be made available. That’s clearly
wrong.

I think we are going in circles, perhaps because of distractions and
breaks in the conversation. While I’m slightly concerned about the
restarter condition–triggering condition relationship, I don’t prefer
any of the alternatives we’ve discussed. I also think the system
presented in the current draft does what it’s meant to do. After
removing the restarter condition predicate field (which we determined
is unneeded) and adding the ‘raise’ and ‘raise-continuable’ restarter
tags, I will ask Arthur to finalize this.

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