Am Di., 3. Dez. 2024 um 21:04 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Marc,
>
> On 2024-12-03 11:17 +0100, Marc Nieper-Wißkirchen wrote:
> > Am Di., 3. Dez. 2024 um 06:36 Uhr schrieb Arthur A. Gleckler
> > <xxxxxx@speechcode.com>:
> > >
> > > Here are Wolfgang's comments on the draft:
> > >
> > > I've generalized interactor procedures to take a condition object, rather than a list of restarters (as they do in SRFI 249). This gives interactors access to the condition raised by the triggering exception, which may include important information (e.g. message, who, and irritants data). In the old model, this information was filtered out. Thanks to Arthur A. Gleckler for pointing out this limitation.
> >
> > This wasn't meant as a limitation in the previous model but was
> > modelling an abstraction barrier. If parts of the condition object are
> > relevant for the interactor, that part of the code that packages the
> > restarters (and which has access to the conditions) should package
> > what's needed to know about the conditions in the restarter closures.
>
> I can’t see a compelling reason for this abstraction barrier. An
> “unsupervised restart” implemented with ‘guard’ has access to the
> original condition, so why should an interactive restart be denied it?

If an interacter just gets the (compound) condition object, it feels
ugly when a distinction is being made between 0 restarters in the
condition object and 1+ restarters in it. In other words, if this
model is chosen, the interacter should always be called regardless of
whether restarter conditions are in the compound condition. It is then
up to the interacter to decide whether to re-raise a condition object
without restarters or to offer default restarters.

This model simplifies the semantics in that there will be less
overhead on top of what is already present in the scheme; an
interactor would just be an exception handler.

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.

> Maybe you could give an example of “packag[ing] what’s needed to know
> about the conditions”. At the moment, the invoker is the only place
> this information could be stored, and the call to that procedure
> occurs at the end of the interactive restart process. How could a
> restarter communicate the irritants of the original condition to
> the user before a restart is chosen? (Passing them in the who or
> description fields would be a hack.)

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.

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.

Does it make sense?

Marc