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