On Fri, 2008-12-26 at 15:38 +0100, Peter Verswyvelen wrote:
Using GHCi I found it informative to see that IO indeed is a kind of state monad. Here's a GHCi session to show that:
Prelude> :m GHC.Prim Prelude GHC.Prim> :i IO newtype IO a = GHC.IOBase.IO (State# RealWorld -> (# State# RealWorld, a #)) -- Defined in GHC.IOBase instance Monad IO -- Defined in GHC.IOBase instance Functor IO -- Defined in GHC.IOBase
So every "IO a" action takes the RealWorld as input, and outputs the RealWorld and some extra value "a" :) [snip]
Thanks to all who've replied! So, the way I get it, everything in Haskell is a function, including IO. Moreover, there exist mathematical foundations for what functions are, in set theory and, more modern, more expressive, in category theory. However, some functions in Haskell may have side effects, like printing something on the screen, updating a database, or producing a random number. These functions are called 'actions' in Haskell. Now I'm starting to guess... There is no mathematical foundation for these side effects (likewise for persistent data), yet they are needed sometimes. However, there is a mechanism (sometimes) to compose functions using an extra type m a, m b, m c etc. instead of types a, b, c... This does not solve the problem concerning side effects, but it does provide a sort of 'Chinese boxes' to contain them within these type constructors m. Moreover, in the case of the type designation 'IO ...', you can't get anything out of the box. So now, at least, you've got a clean interface between the parts of your program which do not involve side effects, and the 'actions'. If I guess correctly, then the general statement 'monads are for actions' is wrong. It should be something like, 'monadic composition is a useful method of generalization, which, by the way, allows you to isolate side effects in a controlled manner'. Regards, Hans van Thiel