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.