It's that a monad looks pure, but actually isn't. Call addition with the same args and you should get the same answer. Calling next on a stream of io is destructive.

> ...a monad looks pure, but actually isn't.

This is not true. The arguments for `next` include both:

* The target stream.

* A "state token" or universe.

You get different results with different state tokens.

At a high level, the thing to consider is that we can model all imperative programming with functional programming -- we can model Turing Machines with Lambda Calculus -- as well as go the other way around, because Turing Machines and the Lambda Calculus are, for all intents and purposes, equivalently expressive.

Modeling IO with state monads isn't a hack; it's the point.

Thank you for the explanation. Haskell's not as bad as I thought in this respect. My understanding was IO streams were a single input function (ie the stream). As a result the destructiveness would be less obvious.

Can you replay a get from stream by passing in an older token?

Because the token is passed only within the implementation of `>>=`, which is private to the IO module, you never have access to it. So no need for the runtime to keep snapshots lying around.

Monads provide a way to combine them and a way to inject values into them; but not all monads provide the inspection interface that would allow you to examine that state token. The definition of a monad guarantees only the injection and the combination (the "unit" and "multiply").

If you call 'next' on an IO stream, you always get the same answer, an IO effect which, when executed, would destructively get the next item:

  next :: Stream a -> IO a

The function part is pure. The `execution` of the resulting `IO a` action (which is completely separate from its pure evaluation) is not.