Talk:Haskell/Understanding monads

From Wikibooks, the open-content textbooks collection

Jump to: navigation, search

Contents

[edit] Archives

[edit] Rewrite of the page?

A complete rewrite of the page seems to have been initiated today. I think it's a shame, since the original version with the nuclear waste metaphor was by far the best tutorial I've ever seen. Since I couldn't find any discussion of this huge change anywhere, I've reverted Apfelmus's changes. --Nattfodd 14:00, 3 August 2007 (UTC)

Thanks, Natt. The discussion (confusingly) took place on Nuclear waste#Unhappy customers. The problem with the original version is that it gives only a superficial understanding of monads and doesn't help the reader to really "get" the point (I say this because I am guilty for most of it). Reverting your revert. Apfelmus is a well trusted member of this community. He understands the strengths of the original version and will likely find a way to preserve them whilst overcoming the major shortcomings :-) -- Kowey 14:07, 3 August 2007 (UTC)
No the metaphor is great! I watched the WIP page, like, "monad is a triplet of (M, return, >==) where they satisfy laws 1, 2 and 3" etc etc. I couldn't get it after staring at it for ten seconds. I'm generally opposed to the "Yankee textbook" style where everything is explained thrice really down-bowing like to a retard monkey, but the other extreme only works if you've got a live instructor. This book's value as a self-study material benefits hugely from such witty and well-written metaphors as in this article! --Sigmundur (talk) 18:01, 2 October 2008 (UTC)
Well, staring at a definition usually doesn't work, the intention was that the reader reads on :-).
The dilemma is the following: if there's no clear definition, some people complain that "monad" is just a buzzword (like "cloud computing" etc.). If there's a metaphor, some people complain that don't see the wood for the metaphorical trees anymore, especially if the metaphor is stretched beyond its limits. If it starts with explaining that IO a is an "action that calculates a value a" (that's how the SPJ's "awkward squad" paper does it and which worked for me), some people complain that this is too abstract either. Hm, now what to do? :-)
-- apfeλmus 09:05, 3 October 2008 (UTC)

[edit] Section "Motivation"

Thanks for taking up on this somewhat stalled text.

A motivating example is a good idea, but it can easily become a demotivating example if it's too complicated/confusing. I think the core idea of safeSqrt is reasonably clear, but the cursory remarks, for instance about <=< and "openness" are too much.

Moreover, I'd certainly avoid saying that monads are "relatively difficult", for they are not, or rather, should not be by virtue of this text.

-- apfeλmus 08:53, 4 August 2009 (UTC)

[edit] Chapter notes and TODOs

[edit] Topics TODO

  • Explain monadic parser combinators! But in another chapter.

  • The basic triad "rock, scissors, paper" err, "reader, writer, state" is best introduced in another chapter, maybe entitled "A Zoo of Monads". Reader must include the famous function [(a->b)] -> a -> [b] also known as sequence!

  • The Random a is too cute to not elaborate it further to probabilistic functional programming. The Monty Hall problem can be solved with that. Key: the implementation can be changed, it effectively becomes the Set-Monad then. Extension: guard and backtracking.

  • Exceptions are a nice way to explain monads, too. See also [1].

[edit] Links

[edit] Obsolete notes

Move the italic inline notes here when no longer necessary.

[edit] What is a monad?

We're bold and present the exact definition of "monad". This should (hopefully) prevent common confusion about the definition and remove the buzzword status. Of course, this paragraph has to be really short since it doesn't explain why I should care about monads at all or what the intuition behind bind and return is.

[edit] Stateful Computations

Example state monads, i.e. particular state types. One of them is to be treated before/in parallel to IO a. The others may be useful for exercises!

  • random numbers. Drawbacks: \gg is meaningless, using an infinite list of random numbers is a better abstraction. Highlights: the state is more an implementation detail than of individual importance, this makes explanation easier!
  • name-supply. Task: label all leaves in a tree from 1 to n.
  • Data.Map for depth first search in a graph.
  • SOE, chapter 19: interactive robot language. Nice example monad to program in. But not a good example for implementation.

Of course, the problem with an example is that we need to explain the example use case before plunging into >>=. But it's probably worth it. Huh, it turns out that we even have to explain the s -> (a,s) pattern for threading state. Seems that random numbers are easiest to explain.

[edit] Materials

[edit] Monad zoo

Just to point out that shapr's girlfriend had some amusing illustrations of monads... might be useful for an eventual Monad Zoo chapter -- Kowey 16:07, 7 August 2007 (UTC)

Marvelous, there more amusement, the better ;-) I intend the "Monad Zoo" chapter to take the role of Haskell/Advanced monads. -- apfeλmus 17:11, 7 August 2007 (UTC)

[edit] Need Images?

I could draw up some preliminary figures/images if you'd like. I'm not familiar with Haskell, but if I can contribute while I learn... why not? :)

Monad state random1.jpg

Monad state random2.jpg

These images correspond to the first monad example, a random number generator.

Oh, thank you! I had something along the lines of the diagrams in the awkward squad paper in mind, though, i.e. something like MonadState sumTwoDice.png. This demonstrates how sumTwoDice is composed of two successive rollDie. Image:monad_state_random2.jpg somehow misses this point :-) I'm not sure wether rectangular boxes are the way to go though, your colorful circles make me thinking.
-- apfeλmus 19:01, 21 February 2008 (UTC)

[edit] Questions and Suggestions

[edit] Prelude and (>>)

We should show a way to hide (>>) and the other monad functions while importing the Prelude.

-- apfeλmus 06:55, 23 April 2009 (UTC)

[edit] How to combine Actions with a function?

For example,I write a function to get the nth fibonacci number.

fib 0 = 1
fib 1 = 1
fib n = fib (n-1) + (fib (n-2))

And it takes long time to get the 1000th number.So I want to show the progress.When it get the 100th,200th,300th,... number,the console print 1,2,3,....How to do this? Must I modify my function or I can make a wrapper of it.

For debugging, you can use Debug.Trace to show intermediate results.
In general, you have to change your function to print something.
fib n = print n >> case n of
  0 -> return 1
  1 -> return 1
  n -> liftM2 (+) (fib (n-1)) (fib (n-2))
Note that your algorithm needs exponential time! I estimate that fib 1000 will take around 10190 years. For better algorithms, see also The Fibonacci sequence on the Haskell Wiki.
The Haskell Cafe Mailinglist is probably better for asking Haskell questions than the wikibook.
-- apfeλmus 13:49, 5 August 2007 (UTC)

[edit] Nomenclature: use of f as a monadic value

In the introductory set of three equations, and throughout, you use x for a value, and f,g,h for either monadic values, or functions. I would use either x, m or a for a monadic variable. i.e.

f >>= return == f

becomes:

a >>= return == a

f is strongly associated with function names. -- Neil Mitchell/ndm

Good point! How do others do it? SPJ in "Tackling the awkwards squad" says
return x >>= f = f x
m >>= return = m
m1 >>= (λx.m2 >>= (λy.m3)) = (m1 >>= (λx.m2)) >>= (λy.m3)

with the condition that x is not free in m3. Wadler in "Monads for functional programming" essentially says

return a >>= λb.n = n[a/b]
m >>= λa.return a = m
m >>= (λa.n >>= λb.o)) = (m >>= λa.n) >>= λb.o

but uses unit and * instead of return> and >>=.

In my own Haskell code, I always use m for monadic values and g,h for functions that return monadic values. That means

return x >>= g = g x
m >>= return = m
(m >>= g) >>= h = m >>= (\x -> g x >>= h)

Hm, do I really do that? Oh, dear. I guess just using m for monadic values and f,g for the functions is probably best. Hm, but the other versions of the associative law are more associative.

-- apfeλmus 09:19, 6 August 2007 (UTC)

[edit] Trouble with currying

I'm not confident enough in my Haskell knowledge to outright correct this, but something looks wrong to me. In the section Threading the State with bind, the definition of >> is:

(>>) :: (Seed -> (a,Seed)) -> (Seed -> (b,Seed)) -> (Seed -> (b,Seed))
(>>) f g seed0 = 
  let (result1, seed1) = f seed0
      (result2, seed2) = g seed1
  in (result2, seed2)

It looks like the type signature and definition disagree. In particular, the signature indicates that >> produces a function. However, the definition seems to produce a pair (b, Seed). On the other hand, this might just be Haskell magic. --Bytecrafter 22:00, 11 November 2007 (UTC)

Even more strangely, >> takes three parameters instead of two... Don't worry, this is just Currying :-) For instance, we may say that (+) is a function that takes one parameter and returns a function, i.e. (+) :: Int -> (Int -> Int) and (3 +) :: Int -> Int but we may also think of (+) as taking two parameters.
The definition of >> is similar. Hm, maybe it's better to write
f >> g = \seed0 -> let ... in (result2,seed2),
but the let spans multiple lines, so I'm not sure whether this helps.
-- apfeλmus 12:00, 12 November 2007 (UTC)
OK, I wasn't sure if that was going on or not. I've only ever seen currying in the invocation of functions, not the definition. Does that imply that the following type signatures are equivalent?
(>>) :: (Seed -> (a,Seed)) -> (Seed -> (b,Seed)) -> (Seed -> (b,Seed))
(>>) :: (Seed -> (a,Seed)) -> (Seed -> (b,Seed)) -> Seed -> (b,Seed)
Yes, exactly. -> is right-associative, i.e. A -> B -> C -> D is parsed as A -> (B -> (C -> D)).
I'm sorry to spam up this discussion page (clearly these questions belong on the currying page), but let me share my impressions. As a reader, I came to this page out of order. I know a bit about functional programming, but I only know enough Haskell to be able to read it. I can't really write it. However, I was very interested to learn more about Monads, since the little that I did know led me to believe that they were magical and cool.
No problem, I mean, "out of order" is to the default on the Internet :-) so the/any article should facilitate that. Hm, having an explicit dependency graph for the chapters would be ideal.
I had expected to see that (>>) would return a function, and was a bit surprised to see that the definition didn't seem to match the type signature. There are probably other readers in similar situations. It might make sense to get the type signature and the function definition to agree.
I changed some definitions, better that way?
To counterbalance my criticism, let me also say that this is the single best Monad discussion that I have seen so far. I appreciate the work that people have put into it, and my comments are only intended to help make the article even better! --Bytecrafter 01:28, 13 November 2007 (UTC)
Yes, thanks for your comments! Moreover, there doesn't seem to be an explanation of currying in the wikibook (!? I suppose it's intended to be in Haskell/Higher-order_functions_and_Currying, hm even a bit late for my taste), your remarks brought to light that it's rather absent.
-- apfeλmus 09:37, 14 November 2007 (UTC)

[edit] "What is a monad" missing something?

A monad is a "thing" that can plug into the monadic plumbing system.

Think of an internet enabled appliance. What does that mean? It means a "thing" that can plug into the internet. But the internet is basically just a giant router. The functionality all depends on what's plugged in. If no one ever showed you a web browser or a chat client, then you would probably have no idea what the internet is.

Nevertheless, we can define what a monad is, without giving even the slightest hint of what a monad is good for.

Moved Oddron's addition here because IMHO they don't fit. But they're not without point, what do you want to express, Oddron? What bugs you about the current version?
The section intentionally does not give an explananation of what monads are good for in order to avoid making it sound like a buzzword.
Strictly speaking, there is no "monadic pumbling system". I don't like the internet example, though it does have the good point that there are many very different monads, i.e. that "monad" itself is a rather bare-bones concept.
-- apfeλmus 07:47, 6 June 2008 (UTC)

[edit] Doubts

[edit] Subsection "What is a Monad?"

In the Right unit law, is m a generic type variable or is it of the monad type M?

Similarly with the Associativity law. GPhilip (talk) 12:50, 7 July 2008 (UTC)

In both cases, m denotes a value of type M a (for some type a). -- apfeλmus 21:24, 7 July 2008 (UTC)
Retrieved from "http://en.wikibooks.org/wiki/Talk:Haskell/Understanding_monads"