[boost] Re: Review Request: FC++

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
>    http://www.nomaware.com/monads/html/index.html
> 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
www.boost-consulting.com