3 ms·

The IO monad doesn't involve actually recording anything...it's not like MVCC. What are you actually trying to say here?

virmundi 11y ago
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.
- Peaker 11y ago
  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.
- solidsnack9000 11y ago
  > ...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.
  - virmundi 11y ago
    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?
    - solidsnack9000 11y ago
      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").

virmundi 11y ago

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.

Peaker 11y ago
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.
solidsnack9000 11y ago
> ...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.
- virmundi 11y ago
  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?
  - solidsnack9000 11y ago
    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").