Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 06 Jun 2020 17:25 UTC
Re: Add further conversions between data-directed and code-directed programming idioms John Cowan 06 Jun 2020 23:27 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 09:13 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Lassi Kortela 07 Jun 2020 12:18 UTC
Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 13:25 UTC
Low-level vs high-level exceptions Lassi Kortela 07 Jun 2020 13:59 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 07 Jun 2020 15:45 UTC
Re: Low-level vs high-level exceptions John Cowan 08 Jun 2020 14:29 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:36 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 08 Jun 2020 14:52 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 09 Jun 2020 06:11 UTC
Re: Low-level vs high-level exceptions Wolfgang Corcoran-Mathe 09 Jun 2020 13:03 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 00:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 10:37 UTC
Re: Low-level vs high-level exceptions John Cowan 14 Jun 2020 14:57 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:31 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 14 Jun 2020 15:42 UTC
Re: Low-level vs high-level exceptions John Cowan 16 Jun 2020 01:58 UTC
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen 16 Jun 2020 07:33 UTC

Re: Add further conversions between data-directed and code-directed programming idioms Marc Nieper-Wißkirchen 07 Jun 2020 09:13 UTC

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