[Haskell-cafe] Monad Description For Imperative Programmer
dry.green.tea at gmail.com
Wed Aug 1 21:20:30 EDT 2007
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
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. :-)
More information about the Haskell-Cafe