On impurity (and Haskell)

Impurity comes in two forms:

Modification of non-local state of the program in a function (internal impurity)
Interactions with the external world (external impurity)

A C example of internal impurity would be passing a value by pointer, and examples of external impurity would be calling printf or srand(time(NULL)).

Importantly, internal impurity is not a thing in pure languages such as Haskell. External impurity is, though. Wait, didn't I just call Haskell a pure language? How can a pure language be compatible with impurity? The thing is, in Haskell, everything I/O related is done in a monad, which makes it magically pure.

Yeah, just kidding. I mean it is really done through a monad, which is neat and tidy, but I still I don't buy into pure side-effects. What people really mean when they call Haskell's I/O model pure is that you could sort of pretend that a Haskell program runs in two phases: first a so-called "IO action" is built (in pure Haskell), then an impure interpreter runs this action (outside of Haskell).

This somewhat matches how things work in practice: compiling a program is equivalent to evaluating the pure sections of the program and the rest is managed by the runtime system. However, "the rest" may be basically the whole program. Consider this contrived example:

main :: IO () main = do let max = 20 + 20 gen <- getStdGen let (rand, _) = randomR (0, max) gen :: (Int, StdGen) if rand == 10 + 5 then putStrLn "branch 1" else putStrLn "branch 2"

Here's what we may picture it to look like after the pure portions have been dealt with:

let max = 20 + 20 gen <- getStdGen let (rand, _) = randomR (0, max 40) gen :: (Int, StdGen) if rand == 10 + 5 15 then putStrLn "branch 1" else putStrLn "branch 2"

Well, this barely changed anything. Actually, the fact that the compilation deals with the pure parts only could also be said of C (with regard to external impurities only, as some internally impure expressions are or at least could be computed at compile time); yet, this does not feel like a compelling argument for the (external) purity of C.

Anyways, people run Haskell programs precisely for their side-effects and not because they like to look at IO actions, so pretending that the side-effects are not part of the program seems like a stretch.

Notes:

Not only can monads wrap externally impure code, but they can also emulate internal impurity in pure functional languages — I mean, this is basically what monads are about.
You could also emulate purity in imperative languages by foregoing impure features, however this wouldn't magically bring you the benefits of functional programming.
I was surprised not to find any established terminology for internal/external impurity, so I made up my own. I/O and stateful computations fall close to what I mean, but I'm not convinced that most people view e.g. RNG seeding as I/O.
More of a note to self: I guess a way of emulating internal impurity in an otherwise pure language would be by exploiting macros and variables shadowing. Not saying you should.