
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20031020 21:34:27
Brian McNamara <lorgon_at_[hidden]> writes:
> 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 listspecific...
>> >
>> > 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
>
> [a]
>
> , but saying either
>
> [] a
>
> or
>
> 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.
Let's see if I get this. In Haskell, a unary function invocation is
spelled
f x
So it stands to reason that a nullary (or fullycurried) function
invocation is spelled
f
And since Haskell is completely lazy, this makes perfect sense: a
nullary function is a value and (in most [all?] cases) a value is a
nullary function.
Therefore,
[1 2 3]
or
List 1 2 3
can be thought of as a computation.
> 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.
I'm still a little vague on some things. If (State s) is a monad,
what's (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.
Looking again at what you wrote above, I see that it's a function
signature... or maybe I need another lesson in Haskell syntax. Isn't
that what ">" is all about?
> Yes...
>
>> > 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!)
> See
> http://www.nomaware.com/monads/html/laws.html#nowayout
> in the tutorial for a discussion.
>
>> > 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.
>
> 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.
Hokey dokey. I'll read some more.
 Dave Abrahams Boost Consulting www.boostconsulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk