4 ms·

>"When we originally added asynchronous exceptions to Haskell ... was shortly after Java had removed the equivalent feature, because it was impossible to progra

by xamuel 10y ago

>"When we originally added asynchronous exceptions to Haskell ... was shortly after Java had removed the equivalent feature, because it was impossible to program with." >"...if [Haskell wants] to be able to interrupt ... asynchronous exceptions are the only way, because polling would be a side-effect" File under "Indictments against Haskell". We're gonna need a bigger filing cabinet.

ben0x539 10y ago
If it was only possible to do things in Haskell that are also possible in Java, that'd be an indictment against it.
jerf 10y ago
The problem with asynchronous exceptions in languages with unconstrained mutability and effects is that there is no way to guarantee what happens when you get the asynchronous exception, especially when you get another one while the handler is running, and maybe another one while that is running, etc. You can be in the middle of an arbitrary sequence of mutations that you don't expect to be interrupted, in a critical section protected by any number of mutexes or whatever, and then the exception arrives when you weren't expecting it. Then while handling that, another one arrives in the middle of your handler. It turns out there just isn't a solution to this problem for languages that don't have constrained mutation. In Haskell, this turns out to be an occasionally challenging problem rather than an impossible one. As the article said, it does get tricky near a few of the seams, but in most code you can just ignore the problem and not worry about it. Your immutable computation gets interrupted at an arbitrary location in the middle of it, and you just throw away the pure components of the computation and run the cleanup code from "bracket"s. (And other runtime details.) It's the same reason Haskell has usable STM and languages with unconstrained effects do not. (Yes, you can download libraries that are STM for a lot of languages, but they are generally not usable.) In a language with unconstrained mutation and side effects, you can't reasonably roll back a transaction because you can't undo the effects, and you can't constrain the programmer to not use any effects. As it turns out, STM turned out not to be a silver bullet and it's merely a single tool in Haskell's toolbelt, one that isn't even necessarily used that often, but because Haskell could implement it, the Haskell community was able to discover that by using it, rather than just theorizing about how nice it may or may not be if only we could have an implementation.

by xamuel 10y ago

ben0x539 10y ago

If it was only possible to do things in Haskell that are also possible in Java, that'd be an indictment against it.

jerf 10y ago

The problem with asynchronous exceptions in languages with unconstrained mutability and effects is that there is no way to guarantee what happens when you get the asynchronous exception, especially when you get another one while the handler is running, and maybe another one while that is running, etc. You can be in the middle of an arbitrary sequence of mutations that you don't expect to be interrupted, in a critical section protected by any number of mutexes or whatever, and then the exception arrives when you weren't expecting it. Then while handling that, another one arrives in the middle of your handler. It turns out there just isn't a solution to this problem for languages that don't have constrained mutation. In Haskell, this turns out to be an occasionally challenging problem rather than an impossible one. As the article said, it does get tricky near a few of the seams, but in most code you can just ignore the problem and not worry about it. Your immutable computation gets interrupted at an arbitrary location in the middle of it, and you just throw away the pure components of the computation and run the cleanup code from "bracket"s. (And other runtime details.) It's the same reason Haskell has usable STM and languages with unconstrained effects do not. (Yes, you can download libraries that are STM for a lot of languages, but they are generally not usable.) In a language with unconstrained mutation and side effects, you can't reasonably roll back a transaction because you can't undo the effects, and you can't constrain the programmer to not use any effects. As it turns out, STM turned out not to be a silver bullet and it's merely a single tool in Haskell's toolbelt, one that isn't even necessarily used that often, but because Haskell could implement it, the Haskell community was able to discover that by using it, rather than just theorizing about how nice it may or may not be if only we could have an implementation.