My take on Monads

[Erann Gat]

I'd like to test my understanding of Monads by trying to explain them.
I'm pretty sure this explanation is not completely correct, maybe even way
off base, but hopefully if someone who really understands this can point
to where I've gone wrong that will help me grok it.

So here's my current take:

You can emulate side effects in a purely functional language by doing the
following: arrange for every function in addition to its normal arguments
to take an additional argument that represents the "state of the world".
Also, in addition to its normal return value(s) every function returns an
additional value representing the "new state of the world". To emulate a
side effect, a function conses up a new world object that is a copy of the
world object that was passed to it modulo whatever changes it want to
make, and then it returns that new world object as its additional return
value. To emulate imperative programming you arrange for the returned
world object from one function to be passed as the "additional argument"
to the next function that you call.

Monads are a way of formalizing all this and hiding the crufty details
from the user.

How close is that to the truth?

E.

[Brian McNamara!]

gNOS...@jpl.nasa.gov (Erann Gat) once said:
>You can emulate side effects in a purely functional language by doing the
>following: arrange for every function in addition to its normal arguments
>to take an additional argument that represents the "state of the world".
>Also, in addition to its normal return value(s) every function returns an
>additional value representing the "new state of the world". To emulate a
>side effect, a function conses up a new world object that is a copy of the
>world object that was passed to it modulo whatever changes it want to
>make, and then it returns that new world object as its additional return
>value. To emulate imperative programming you arrange for the returned
>world object from one function to be passed as the "additional argument"
>to the next function that you call.
>
>Monads are a way of formalizing all this and hiding the crufty details
>from the user.
>
>How close is that to the truth?

That's a good description of one particular monad (the State monad).
But monads are more general/abstract.

In general, I feel like monads provide a way to "do a bit of extra work
at each point where two smaller computations are composed into a larger
one". In the State monad, the "extra work" is plumbing the "world"
parameter around behind-the-scenes. But, for example, in the Maybe
monad, the extra work is dealing with failure for exception-handling.

--
Brian M. McNamara lor...@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )

[Tim Sweeney]

Monads are a purely functional technique for doing what you just
described, but also a lot more. In Haskell, the language on which
much of the development of monads has been focused, the IO monad is
the monad that implements this "pass the state of the world in and out
of every function" pattern.

Many other interesting programming patterns are possible with monads.
For example, Haskell's State monad enables you to write
self-contained blocks of code using exceptions and heap allocations
whose access is guaranteed to be constrained within that block of
code, so that a function implemented this way is purely functional "on
the outside", though it uses many imperative-style techniques "on the
inside".

Also check out Haskell's Array monad (for computations producing
multiple values) and Maybe monad (for computations that may return an
optional failure code) to get a feeling for some very different
programming techniques encapsulated by monads.