The -> in type signatures associates to the right, so the type signatures

fmap :: (a -> b) -> (W a -> W b) bind :: (a -> W b) -> (W a -> W b)

are the same as:

fmap :: (a -> b) -> W a -> W b bind :: (a -> W b) -> W a -> W b

Sometimes people put in the extra parentheses because they want to emphasize a particular way to use the function. I'm assuming you understand that a function that takes two arguments and returns a (possibly non-function) value is equivalent to a function that takes one argument that returns a function that takes the other argument and returns a value. HTH, Mike Adrian Neumann wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I've read this blogpost about the "trivial monad" http://sigfpe.blogspot.com/2007/04/trivial-monad.html, because I still don't understand what this monad thingy is all about.

The author defines three functions:

data W a = W a deriving Show

return :: a -> W a return x = W x

fmap :: (a -> b) -> (W a -> W b) fmap f (W x) = W (f x)

bind :: (a -> W b) -> (W a -> W b) bind f (W x) = f x

and asks the reader to prove the tree monad laws for them. However I don't understand the type signatures for bind and fmap. I'd say (and ghci's type inference agrees) that bind and fmap have the type

bind:: (a->W b) -> W a -> W b fmap:: (a->b) -> W a -> W b

They take a function f and something and return what f does to that. I don't see why they should return a function.

This of course makes it hard for me to prove the monad laws. The first however works nonetheless:

1) bind f (return a)= f a

=> bind f (return a)= bind f (W a) = f a

Can someone explain bind and fmap (and possible law 2 and 3)?

Thanks,

Adrian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOuQS11V8mqIQMRsRCmngAJ9NwQMwXeS/PSM1NUsVA8gxPuA0KACfSLiA ItqRZW5a4XyQ099bhMtSWmU= =/8i/ -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Adrian,

They take a function f and something and return what f does to that. I don't see why they should return a function.

Consider a function, f, that takes two arguments, one of type A, and one of type B, and returns something of type C. In conventional mathematical notation this would be written as f : A x B -> C. Think about what this function does from a practical point of view. It waits to be handed an object of type A. It then waits for an object of type B. And now it can return an object of type C. But suppose we hand f an object of type A, but not another of type B. What do we get? Well we basically have something that's still waiting for an object of type B, and when it gets that it'll return an object of type C. Something that's waiting for a B in order to give you a C is of type B->C. So after you've given f an A, you get back a B->C. So f can be thought of as being of type A->(B->C). So there are two ways of thinking of f. (1) A function that takes an A and a B and gives you a C. Or (2) a function that takes an A and gives you back a function mapping a B to a C. Haskell blurs the distinction between these things and the transition from view (1) to view (2) is called 'currying'. Internally, the Haskell parser automatically converts A->B->C to A->(B->C) so you can view the former as simply being shorthand for the latter. (In CS-speak '->' is considered to be right associative but that's just another way of saying the same thing.) -- Dan