Am Di., 3. Dez. 2024 um 21:04 Uhr schrieb Wolfgang Corcoran-Mathe <[email protected]>: > > 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 > > <[email protected]>: > > > > > > 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
