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").
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.