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?

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.)

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