Am So., 7. Juni 2020 um 01:28 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> I'm concerned about trapping *all* condition objects (and there is no standard hierarchy of condition types).  There are two particularly bad cases, asynchronous exceptions and exceptions that the implementation relies on not being caught.

> In a Scheme that transforms Posix signals into exceptions, it would be impossible to terminate or stop a process while inside this feature by SIGINT or SIGSTOP (though SIGQUIT and SIGTSTP will still work), nor will SIGBUS be very useful if trapped.  If there were a reliable signal-from-exception? predicate, that would help, but there isn't.  Similarly, an implementation that raises an out-of-memory exception from the GC may find it being swallowed if the GC runs on any random thread rather than its own.

It's not yet clear to me whether it is a good idea (Lassi would say
whether it is "The Right Thing") to transform Posix signals into
exceptions but I agree with you that catching every exception by
default can be very dangerous. Introspection of error conditions would
be simpler if some future part of R7RS-large would reinstall (parts)
of the R6RS condition system. As the standard guard form of R7RS-small
comes with an else clause we must conclude, however, that any Scheme
implementation that relies on certain exceptions not being caused is
brittle. "Exceptions" that mustn't be caught (except by specialized
handlers) shouldn't, therefore, use the standard exception system.
This seems to be true for Posix signals as for OOM exceptions.

Anyway, for the moment being, I would, therefore, revise my proposal to:

(either <thunk> <pred>)

This can be used as in: (either read read-error?)

The implementation is:

(define (either thunk pred)
  (guard (c ((pred c) (left c)) (call-with-values thunk right))))

Marc