Asynchronous Exceptions in Practice

It is not a side-effect because it is part of the execution model.

In other words, it's one of the things you don't care about when writing a pure program, like how many times it runs, how many threads are running it, on what order it executes, etc.

It does leak, but only on the IO monad.

> And how do you need to look at this for it not to be a side-effect?

I would look at it like this: while a function can be pure (no side effects), the thread in which it executes need not be a pure construct. It's a property of the runtime system, which, essentially, schedules pure functions to run inside green threads, to which exceptions can be thrown (which will terminate the execution of the pure function).

I surely don't know as much as simonmar about this, but I think this is a rhetorical shortcut. My understanding is that when a Haskell thread receiving the exception needs to allocate on the heap, the executing context will instead raise the exception.

As for why it's not a side effect, in Haskell all exceptions are considered to be bottom, the value that inhabits every type. Thus an exception can be raised anywhere and have any type. They can only be handled in IO though.

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

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.