[tel]

Perhaps the best way to think of it is that a Haskell program is a pure function from FFI outputs to FFI inputs. Something like

    H out in = out -> (FFIOperation, in)

The `IO` monad is nothing more than how operating "inside of this function" feels. The runtime thus operates the pure Haskell program evaluating its FFI demands and returning their results.

The AST POV espoused by this article is quite good as well, but a little bit less obvious how to "step" things forward or operate nicely in parallel contexts.

Also, in reality the above perspective is a good way to embed Haskell into other contexts.

http://comonad.com/reader/2011/free-monads-for-less-3/

[skybrian]

The way I think of it is that an IO value is a program where all the Haskell code runs in callbacks. This is a bit like a JavaScript program where everything runs in a callback. The major difference is that callbacks written in Haskell are constrained to be pure functions.

The IO type is rather rigid in that there is always a next callback, which implicitly contains the entire program state as part of the function closure. In a reactive programming language like Elm you can have many functions that may be the next callback depending on what the next event is, along with all the callbacks that run as part of the signal graph. Purity is about how constrained the callbacks are, not about the overall structure of the program.