 # Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2003-10-20 20:42:20

Dave wrote:

[snip]
> > represents a "computation which will yield a value of type a".
>
>
> Huh? A list of a's is a computation which yields a value of type a??

Yes, if one regards the list as the choices for the computation, as is
intrinsically the case when programming in the list monad.

Thus, the list [42, 67, 50] corresponds to a computation that could result
in either '42', '67' or '50'.

[snip]
> > What bind() buys us (compared to just using functions and lets, like
> > let a = c1
> > b = c2
> > c = c3
> > in f a b c
> > ) is that it automatically "plumbs through" the essence of
>
> Well, what was suspicious is the imbalance of (a -> m b) as
> opposed to simply (a -> b).

One can lift the plain function (a -> b) into a monadic function (a -> m b),
by using 'unit', or even lift the tail, and achieve a functorial operation
(m a -> m b). The problem is that the first form of lifting merely inserts a
value into the monad. It is often the case that one wants to add some side
effect in the computation of a function, and that side effect needs to be
defined by the function itself, i.e., it needs to be a (a -> m b) function.

It is this interaction between "plain values" and "structures" (a -> m b)
that gives monads the power. The programmer just have to specify how to
enter the monad, the rest is done by the algebraic framework (in this case
FC++), including chaining the computation steps in a consistent flow. These
transitional functions, which you have to provide yourself, are called

It is worth noting that the two operators chosen, 'bind' and 'unit' are not
the only plausible choices for a monad (see 'unit' and 'join')

I think one needs to get acquainted with Category Theory in general, and
Kleisli Categories, specifically, to really enjoy the monadic world. After