I V wrote: > Monads are one of those parts of functional programming I've never really > got my head around, but as I understand them, they're a way of > transforming what looks like a sequence of imperative programming > statements that operate on a global state into a sequence of function > calls that pass the state between them.
This is a description of only one particular kind of monad - a state monad. A generalisation of your statement would be something like this: "they're a way of writing what looks like a sequence of imperative programming statements that, depending on the monad, can have certain computational side-effects (like operating on a global state) in a purely functional way". But this doesn't explain much. If you want to know more, there are some pretty good tutorials on http://www.haskell.org/. > So, what would be a statement in an imperative language is an anonymous > function that gets added to the monad, and then, when the monad is run, > these functions get executed. A monad is a type, it isn't run. The thing you run can be called a monadic action. You don't add functions to a monad (in this sense), you build a monadic action from smaller monadic actions, gluing them with functions - here's where anonymous functions are natural. > The point being, that you have a lot of small functions (one for each > statement) which are likely not to be used anywhere else, so defining > them as named functions would be a bit of a pain in the arse. Exactly! > Actually, defining them as unnamed functions via lambdas would be annoying > too, although not as annoying as using named functions - what you really > want is macros, so that what looks like a statement can be interpreted is > a piece of code to be executed later. Haskell has one such "macro" - this is the do-notation syntax. But it's translation to ordinary lambdas is very straightforward, and the choice between using the do-notation or lambdas with >>= is a matter of style. Best regards Tomasz -- http://mail.python.org/mailman/listinfo/python-list
