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