Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-20 14:09:06

On Mon, Oct 20, 2003 at 02:32:34PM -0400, David Abrahams wrote:
> Brian McNamara <lorgon_at_[hidden]> writes:
> > Let me see if I can allay any suspicions that monad signatures are in
> > any way list-specific...
> >
> > In general, given a monad "m",
> e.g. []
> > the type "m a"
> e.g. [] a or a list of a's

(Right; in Haskell it's actually spelled


, but saying either

   [] a


   List a

is fine, as you've still "got" the essential idea.)

> > 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??
> I must be off track here.

I foresaw this, which is why I wrote:

> > (The word "computation" is not the most intuitive word, but I don't
> > know that there is a better word which captures the notion of what
> > monads abstract on, and "computation" seems to be the de facto
> > standard that's used in the papers I've seen which try to explain
> > monads.)

The list [1 2 3] can be thought of as a computation which yields each
of the values 1, 2, and 3. Or at least that's how you have to think of
it when you have your monad hat on. Many monads use a function type as
their representation, which makes the word "computation" seem more
apt. With the State monad, for example:

   -- (State s) is a monad
   type State s a = s -> (a,s)

it makes more intuitive sense. You can think of the state monad as a
"computation" which, when passed an initial state (of type "s"),
returns a pair of some value (of type "a") along with the (possibly
updated) state.

> > the results. This is why bind() has the signature it does. A typical
> > string of operations in a monad looks like this:
> > comp1 `bind` \a -> -- run comp1, store result in 'a'
> > comp2 `bind` \b -> -- run comp2, store result in 'b'
> > comp3 `bind` \c -> -- run comp3, store result in 'c'
> > unit (f a b c) -- compute some function of a, b, and c
> > That whole expression has type "m r".
> I think that little word "in" is crucial here.


> > 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 the monad.
> Well, what was suspicious is the imbalance of (a -> m b) as opposed to
> simply (a -> b). I understand that the type "m b" is different from
> just "b" but so far all the examples I've seen just store one or more
> instances of the monad's parameter so I guess that's throwing me off.

... one of the interesting things about the monad interface is that you
can get into a monad, but there's no general way to get out. (Trapped!)
in the tutorial for a discussion.

> > It might be helpful to check out
> >
> > and look at {Identity,Maybe,List,State} in Part II. The state monad, in
> > particular, is one of the best motivating examples for monads, since
> > it's so familiar.
> OK, will do.

I should have mentioned before:

   FC++ name Haskell name Other common names
   --------- ------------ ------------------
    unit return result
    bind >>= then, comb
    zero mzero
    plus mplus

That is, depending on what language/tutorial you're reading, the names
of the methods in the "monad interface" may be different.

-Brian McNamara (lorgon_at_[hidden])

Boost list run by bdawes at, gregod at, cpdaniel at, john at