undefined | Better HN

0 pointsjandrese1y ago0 comments

Or it's nearly impossible for a pure functional language if the result of the async signal means you need to mutate some state elsewhere in the program to deal with the issue.

0 comments

ratorx1y ago

I think that’s slightly orthogonal. It would still be safe, because you’d design around this restriction from the start, rather than accidentally call or mutate something you were not supposed to.

The problem with safe signal handling is that you need to verify that your entire signal handler call stack is async safe. Assuming purity is a stronger property, signal handling is a safe API without any more work.

The inflexibility due to the purity might cause other issues but that’s more a language level concern. If the signal handling API is safe and inflexible, it still seems better for a lot of use cases than an unsafe by default one.

o11c1y ago

The real problem is that the compiler doesn't provide arbitrary function-colorings, only the a handful of builtins: `pure`, `const`, `noreturn`.

s-zeng1y ago

Monads can be thought of as arbitrary function colourings, hence the prior mention of Haskell potentially being a good fit. Of course monads are implementable in almost any other language, but few have as much syntax sugar or general library support as Haskell does, except maybe Ocaml

1 more reply

j / k navigate · click thread line to collapse