Adrian Neumann
Am 23.12.2008 um 15:16 schrieb Hans van Thiel:
I just saw somewhere that one of the purposes of monads is to capture side effects. I understand what a side effect is in C, for example. Say you want to switch the contents of two variables. Then you need a third temporary variable to store an intermediate result. If this is global, then it will be changed by the operation.
[...]
However when you *do* want state you can simulate it with a monad. The IO Monad is a special case here, since its actions don't change your program, they change the "world" the program is running in (writing files etc.). getLine etc are functions when you think of them as taking a hidden parameter, the state of the world. So getChar would become
getChar :: World -> (Char,World)
but the world stays hidden inside the IO Monad.
Yes, I like this view, but you shouldn't say that the world is hidden inside the IO monad, because you can easily use part of that state in computations. In my view, the IO monad is some notion of this: type IO = State World The main difference between this and the real IO is that there is no value for the (entire) world's state you could refer to, which eliminates the need for 'get', 'put', and by introducing a 'main' computation, also 'runState' becomes unnecessary. In fact, this makes the whole 'World' type unnecessary. So IO is really just a theoretical construct to make input/output consistent with referential transparency. This is a very short version of what I have written in section 7 [1] of my monads tutorial. [1] http://ertes.de/articles/monads.html#section-7 Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/