[Haskell-cafe] Monad Description For Imperative Programmer

[Alexis Hazell]

On Thursday 02 August 2007 08:17, Claus Reinke wrote:
> a Monad is a type constructor with two operations, implementing
> a standard interface and following a few simple rules.

. . . . and this is one of the best definitions i've seen yet. Thanks Claus!

i think we need to be looking at "What is a Monad?" issue from the point of 
view of putting together a Dictionary of Haskell. There's no room for long 
explanations - just a concise sentence or two that gets to the heart of what 
a Haskell Monad is.

Personally, my feeling is that people are scared by Monads, not because of the 
name, but because whenever they ask about what a Monad essentially /is/, they 
get a plethora of less-than-concise explanations that often don't include the 
sort of straightforward starting definition than Claus has presented here. No 
wonder Monads seem scary when even experienced Haskell programmers put 
forward such a variety of attempts to describe what a Monad actually is! (In 
some ways, i'm reminded of discussions about what continuations are - many 
definitions are vague and involve hand-waving; only a few seem to provide a 
straightforward technical definition that doesn't skirt around the guts of 
the matter.)

That's why i've banged on about presenting my own attempt at a concise 
definition - not because i think my definition is that great at all, but 
because it at least represents a starting point to work towards developing a 
concise definition that we can quote and /then/ elaborate on in the way that 
we think is most likely to convey how Monads work to the querent in question. 
And again, i really like Claus' elaboration:

> the Monad type class tells you the interface (what operations
> you've got, and their types), the Monad laws tell you what all
> types implementing that interface should have in common.
>
> the monadic interface gives you two operations, one to throw
> things into a monad thing (return), and one to chain two monad
> things together (>>=). the chaining explicitly caters for information
> flowing from the first to the second parameter of (>>=).
>
> the monad laws tell you two useful facts about monad things
> thrown together in that way: whatever it is the monad does,
> anything just thrown into it will take no part in that action,
> and whichever way you use that chaining operation, the
> structure of chaining is irrelevant, only the ordering of chained
> monad things matters.
>
> there are usually other ways to create 'primitive' monadic things,
> which can be combined into complex monadic structures using
> the operations from the Monad interface.
>
> there is usually a way to interpret monadic structures built in
> this way (a 'run' operation of some kind).

Category theorists can define monads concisely using the language of their 
discipline - surely we can settle on a definition of Haskell Monads that 
would make sense to any programmer who has mastered basic programming 
concepts? i would suggest that Claus' definition, above, would be a great 
place to start. :-)


Alexis.