]>
Here's my layman's perspective...
I think the most important thing to understand about monads is that
they allow a bit of data (state) to follow the control flow of your
program... around loops (via tail-recursion), through assignments (via
the 'bind' operator) and out of one routine and into another (via
'return'). As the state goes along for this ride, it can be accessed
and updated (replaced with a new state). This is how Haskell
implements imperative constructs -- it propagates them in this bit of
state that flows through the program.
To understand this, I would start with the state-transition monad.
There it's easy to see how 'bind' propagates state, and how 'return'
packages state into the result.
Things get interesting with monads when this state contains
continuations -- functions that have been captured along the way and
stored in the state can be later invoked to return control to previous
points in your program. A monadic version of call/cc (e.g. from
scheme) can be implemented this way. This is essentially what enables
lightweight thread packages like Lwt to suspend and resume control.
Perhaps one non-obvious thing about monads is how they hide this state
from the program that uses it. Operations that are "in the monad" can
see an manipulate the state. It appears as additional parameters to
the operation, or (more accurately) as parameters to a function being
returned from the monadic operation. Operations that simply use the
monad are really composing these functional pieces together (along
with their own bits of non-monadic code) to build up bigger monadic
operations.
Running a monadic program really has 2 distinct phases: First
composing all the pieces together (which is why it's critical that non-
monadic operations be lazy or hidden inside functions that defer them
until the second phase). (Monadic interpreters use the AST to drive
this composition process.) Second is the application to the state
which puts the whole machine in motion, producing the final result or
effect of the program.
I hope this explanation helps. I've found monads to be an amazing
powerful abstraction, although the explanations of them are often
academic and difficult to get one's head around. Understanding them
can open many new possibilities however,
Warren
On Jul 21, 2008, at 2:28 PM, Paolo Donadeo - p.donadeo@gmail.com wrote:
> I'm disappointed with myself and my incredibly low IQ. Late this
> evening I decided -- and this is the third time -- to be enlightened
> by the concept of monad.
>
> I like functional programming, but monads [1] must be too little to be
> grabbed by my mind. This time the interest in monads was aroused by
> the interesting article of David Teller, Arnaud Spiwack and Till
> Varoquaux [2] about the error monad, but for using the library they
> wrote I need at least some knowledge about monads and the do-notation.
>
> I tried with some tutorials found around, but I still cannot catch the
> point: what the hell is a monad?
>
> I ask you all: can anyone make me a practical example, something
> involving strings, files, the network, an image or sound processing
> algorithm, something vaguely real? Not abstract mathematical
> structures, beautiful algebraic properties and general statements,
> please: the net is full of such tutorials, especially Haskell fan
> sites ;-)
>
> Thanks in advance for your patience.
>
>
> [1] http://en.wikipedia.org/wiki/Monad_(symbol)
> [2] http://www.univ-orleans.fr/lifo/Members/David.Teller/publications/ml2008.pdf
>
>
> --
> Ing. Paolo Donadeo
> Studio Associato 4Sigma
> Website: http://www.4sigma.it
> Personal website: http://www.donadeo.net/blog
> ~
> ~
> :wq
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs