| It's a shame he's put an introduction to monads smack down in the middle of this otherwise nice argument. If there was ever any objection to pure functional programming it would be that monads are complex and hard to learn and reason about. Putting an explanation of them with all sorts of mathematical terms is not helping the cause. Not only are monads not the only solution to doing I/O in a pure programming language (stream based I/O or functional reactive being another), they need not such a mathematical explanation. An I/O monad is a simple class modelling a box. There's two functions for it, one puts something that's not in a box in a box. The other function allows you to give it a function that is applied over the function in the box, without taking it out of the box (this is called a 'bind' operation). Note that there's no function to take the value out of the box. The trick is that the only thing that knows how to get the value out of the box is the VM itself. So its task is to at the end of your function, execute whatever function created your monad, and then execute all functions you gave it using the 'bind' functions sequentially over the returned value (which might include unwrapping more i/o monads). Since every bind function relies on the previous value of the monad, it can naturally only be executed sequentially. Note that this explanation does not explain monads either in full or very accurately, it's just one of the patterns that monads are used in, and hopefully gives you an idea about how it is that monads are used to enforce encapsulation and sequential execution of effectful functions. |