Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-20 13:32:58

Brian McNamara <lorgon_at_[hidden]> writes:

> On Mon, Oct 20, 2003 at 10:25:53AM -0400, David Abrahams wrote:
>> > [ x+y | x <- [1,2,3], y <- [0,10] ] -- yields [1,11,2,12,3,13]
>> >
>> > is just syntactic sugar for
>> >
>> > [1,2,3] `bind` \x ->
>> > [0,10] `bind` \y ->
>> > unit (x+y)
>> I see that happening, and it makes sense... but it's not at all clear
>> to me that the Haskell designers have ahold of something fundamental
>> and important in that bind signature. It seems somewhat arbitrary.
>> > In my experience, you have to do a few passes on monads before it
>> > becomes clear how the basic monad stuff is motivated by the final
>> > results of using monads.
>> I guess I'm wondering how much of the basic monad stuff is motivated
>> by the final results in the specific case of the list monad. The
>> signature of the "k" function (a -> m b) seems particularly
>> suspicious to me.
> 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

> 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.

> (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.)
> bind() gives us a way to sequence monad computations. If we have
> comp1 :: m a
> comp2 :: m b
> comp3 :: m c
> f :: a -> b -> c -> r
> then we may want to run these computations in sequence and operate on
> 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.

> 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.

Dave Abrahams
Boost Consulting

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