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:46 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:04 UTC)
Re: Low-level vs high-level exceptions John Cowan (14 Jun 2020 00:59 UTC)
Re: Low-level vs high-level exceptions Marc Nieper-Wißkirchen (14 Jun 2020 10:38 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:32 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 13:25 UTC

Am So., 7. Juni 2020 um 14:18 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> Sounds quite dangerous. Signals and threads go together like diet coke
> and mentos :)

I tried this experiment a few weeks ago with my children. It works!

> As one pitfall, there must be a decision in which thread the signal
> handler is run and whether or not other threads are stopped. Some OSes
> even have a separate signal stack. I'm sure there are many more footguns
> involving I/O interruptions, continuations and FFI for starters.

Modelling synchronous signals like SIGSEGV as Scheme exceptions may
make more sense if these exceptions are continuable.

> > but I agree with you that catching every exception by
> > default can be very dangerous.
>
> +1

It may make sense to define a class of exceptions that cannot be
caught by user provided handlers. This can include all exceptions a
Scheme system raises where the standard just says "... it is an
error". (*)

Even when such an exception is caught, there is not much portable code
do with it anyway (maybe except for logging it and reraising it; but
even logging may be dangerous when it is not clear how severe the
exception is that has been caught).

The advantage of (*) is also that the danger inherent in the
else-clause in the standard guard form would be diminished.