Someone recently noted in the #haskell IRC channel that
Monads are a concept from category theory, where they're also known as triples and 'standard constructions'. One doesn't have to understand their theoretical underpinnings in order to understand their function in Haskell, however. Monads are a way of isolating parts of the program that violate referential transparency - that is, that have significant side-effects - from the rest of the purely functional program.
Usually, the first monad that Haskell beginners come across is the IO monad - the monad required to utilise STDIN and STDOUT. This tends to cause some consternation, along the lines of "I have to learn about monads just to print some text?!?" It also tends to give the impression that monads are some kind of kludgy band-aid to enable side-effects in an otherwise purely functional language. But they're not. Haskell monads are actually very powerful, as they can be used to provide more control over one's programming environment than one would otherwise have. i'll come back to this below.
People have tried to communicate what Haskell monads are about in various ways: via 'container' metaphors (e.g. this and this; i found the former to be more illuminating than the latter); via relationship metaphors (e.g. this, which i found more confusing than helpful), and even via a 'monsters' metaphor (which i found to be rather amusing)1. One tutorial that people on the Haskell-café list seem eager to recommend (and that's recommended on the Haskellwiki) is All about monads, but that just overwhelmed me when i first read it; and even now, when i've got a better understanding of monads, i still find it difficult to follow. In contrast, i found Tackling the awkward squad and Monads for functional programming to both be very enlightening.
As far as i can tell, however, a monad simply seems to be a computational environment in which one can specify that certain types and methods of computation be performed, and in which the three monad laws are expected to hold. Within that framework, one can establish a variety of computational approaches: not only can one write in an imperative style, for example (using what's referred to as do-notation), one can also create an environment for exception-based programming (e.g. Control.Exception) or which uses continuations (e.g. Control.Monad.Cont) or which uses Software Transactional Memory2 (e.g. Control.Monad.STM) .
Given this, suggesting that monads are merely a 'kludge' to make 'feature-poor' Haskell reasonably useful is like suggesting that operating systems are merely a 'kludge' to make PCs useful. Sure, one can 'hard-wire' certain behaviour into a particular piece of hardware (e.g. televisions) - but then that piece of hardware doesn't have as much flexibility, and one is stuck with the pre-provided functionality - which one can only build on top of, and which is difficult to change should the extended functionality require it. So in a sense, monads provide Haskell with the ability to change how the language works in a way reminiscent of dialects of Lisp.
And that's my monad 'tutorial'. :-)
1. i actually agree with a comment made on reddit that:
A 'newbie', in Haskell, is someone who hasn't yet implemented a compiler. They've only written a monad tutorial.This is a nod to the plethora of extant tutorials about this concept, which (i feel) extends Haskell from being mainly of academic interest to being more of a language for day-to-day programming.
Monads are a concept from category theory, where they're also known as triples and 'standard constructions'. One doesn't have to understand their theoretical underpinnings in order to understand their function in Haskell, however. Monads are a way of isolating parts of the program that violate referential transparency - that is, that have significant side-effects - from the rest of the purely functional program.
Usually, the first monad that Haskell beginners come across is the IO monad - the monad required to utilise STDIN and STDOUT. This tends to cause some consternation, along the lines of "I have to learn about monads just to print some text?!?" It also tends to give the impression that monads are some kind of kludgy band-aid to enable side-effects in an otherwise purely functional language. But they're not. Haskell monads are actually very powerful, as they can be used to provide more control over one's programming environment than one would otherwise have. i'll come back to this below.
People have tried to communicate what Haskell monads are about in various ways: via 'container' metaphors (e.g. this and this; i found the former to be more illuminating than the latter); via relationship metaphors (e.g. this, which i found more confusing than helpful), and even via a 'monsters' metaphor (which i found to be rather amusing)1. One tutorial that people on the Haskell-café list seem eager to recommend (and that's recommended on the Haskellwiki) is All about monads, but that just overwhelmed me when i first read it; and even now, when i've got a better understanding of monads, i still find it difficult to follow. In contrast, i found Tackling the awkward squad and Monads for functional programming to both be very enlightening.
As far as i can tell, however, a monad simply seems to be a computational environment in which one can specify that certain types and methods of computation be performed, and in which the three monad laws are expected to hold. Within that framework, one can establish a variety of computational approaches: not only can one write in an imperative style, for example (using what's referred to as do-notation), one can also create an environment for exception-based programming (e.g. Control.Exception) or which uses continuations (e.g. Control.Monad.Cont) or which uses Software Transactional Memory2 (e.g. Control.Monad.STM) .
Given this, suggesting that monads are merely a 'kludge' to make 'feature-poor' Haskell reasonably useful is like suggesting that operating systems are merely a 'kludge' to make PCs useful. Sure, one can 'hard-wire' certain behaviour into a particular piece of hardware (e.g. televisions) - but then that piece of hardware doesn't have as much flexibility, and one is stuck with the pre-provided functionality - which one can only build on top of, and which is difficult to change should the extended functionality require it. So in a sense, monads provide Haskell with the ability to change how the language works in a way reminiscent of dialects of Lisp.
And that's my monad 'tutorial'. :-)
1. i actually agree with a comment made on reddit that:
Maybe one of the problems with the proliferation of monad tutorials and other newbie Haskell tutorials is assuming that there can be a single metaphor that suits everyone and all learning styles.2. i found Simon Peyton Jones' recent paper Beautiful concurrency to be a good introduction to STM in Haskell.