On 2024-12-11 09:14 +0100, Marc Nieper-Wißkirchen wrote:
> To simplify further, "with-current-interactor" could probably be
> removed. The "current interactor" would then be like Chez's
> "base-exception-handler". Indeed, it doesn't seem to make sense to
> nest "with-current-interactor", so it should be part of the exception
> system.

It would indeed be nice to standardize the ‘base-exception-handler’
parameter as an interactor. But it’s not necessary to do this in
SRFI 255. The definition of interactors is useful and portable,
so that programmers can use SRFI 255 even if their implementation
doesn’t provide an interactive handler. If it does, they can ignore
SRFI 255’s interactor forms without issue.

So I’d like to put off specifying ‘base-exception-handler’ to another
SRFI.

> Maybe we can discuss this in detail if the other model is not chosen.
> In general, having only a "who" and a "description" field is limiting
> in any case. This may be sufficient information for some interactors
> but not for all.

Yes, but restarter fields aren’t a great place for information about
the triggering exception. Let us say you want to present the message
of the original condition to the user before a restarter is chosen. If
this requires storing it in some restarter field, then which restarter
gets it? There may be many. This message, moreover, is not specific
to any particular restarter, but rather to the *event* which is being
restarted. It’s natural to describe that event with a single, composite
condition including the original condition and all available restarters.

> Accessing the condition does not help much because the final condition
> object may not be related to the condition object that was present
> when the restarter was added so the interaction with a particular
> restarter should not depend on the final condition object.

I’m not sure I understand this. I think you mean that the final
condition could contain information that’s irrelevant to some of the
restarters, or perhaps confusing. How would you prune it, then?

(This suggestion also seems to be tacking back toward the
list-of-restarters model of interactors, which is incompatible with
the current interactor-as-talkative-exception-handler model. Or
perhaps I’ve misunderstood.)

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