This [1] was the explanation which finally made monads "click" for me. You can think of the IO monad as a way to force a compile-time dependency between I/O ope

This [1] was the explanation which finally made monads "click" for me. You can think of the IO monad as a way to force a compile-time dependency between I/O operations by having each IO-performing function take a "baton" value (the "IO" instance) as an argument, as well as return it. The explanation of how Haskell retains the appearance of purity in the face of impure I/O by passing an instance of RealWorld around is genius. That's a brilliant way to start out explaining monads, and it's something simple that you can use to explain the other monads such as the state monad (which the IO monad is built on). [1] http://www.haskell.org/haskellwiki/IO_inside http://www.haskell.org/haskellwiki/IO_inside