Talk:Haskell/Understanding monads/List

TODO
(Copying TODO list originally in the article. As of now I see the points as nice to have but not too urgent.) TODO: --Duplode (discuss • contribs) 07:38, 1 May 2012 (UTC)
 * Example: 
 * relation to 
 * nondeterminism

Style
Isn't it bad style to write do bd0 <- return bd Instead of do let bd0 = bd ?


 * I can't see any reason to put in these redundant return clauses that have no effect. I talked with others about this even. I'm removing them from here and already removed the same clutter from other monad examples in the previous chapters. Backfromquadrangle (discuss • contribs) 06:43, 2 May 2014 (UTC)

Removing regressive examples of pre-monad approaches
It seems awfully confusing to me to be learning about monads and have long sections that go on about how to achieve things with clunky code that is redundant to monads. We spent the time to learn how monads work, now is the time to understand and use them. I don't want to see how to make do without them. I'm removing the extraneous stuff and sticking to explaining how to actually use monads. It is fair at this point to assume that readers understand something about what monads are and why they work. They just need to keep experiencing them to get comfortable. Avoiding them and then re-explaining them is mostly confusing. Backfromquadrangle (discuss • contribs) 06:43, 2 May 2014 (UTC)


 * That is the right thing to do. The issues were due to historical accident: those chapters about common monads came into being when the old Understanding Monads and its deprecated follow-up Advanced Monads were exploded, and they were never fully tuned to the new surrounding text. Until now, that is :)--Duplode (discuss • contribs) 15:30, 2 May 2014 (UTC)

Lousy word problems
The word problems were too specific and too contrived and even innacurate and the code then basically avoided addressing them in any real way. I simplified them but left in the gist.

Better explanation needed for how do notation does binding
I get that do notation does binding, but where the variable assignment fits in confuses me. The variable must be non-monadic (not a list in this case), but yet there must be able to be multiple items (given a list with many elements) that the same placeholder variable stands for. Somehow this should be made more clear and explicit to understand how do is syntactic sugar for bind.Backfromquadrangle (discuss • contribs) 06:41, 5 May 2014 (UTC)


 * The gist of it is that when you use the left arrow you are actually defining a lambda to be used with, with the variable standing for the argument and the rest of the do-block being the result value. For the list monad, the magic is at   being (flipped)  , which implies the lambda will be mapped over the list at the right of the arrow (from which the multiple items come from).--Duplode (discuss • contribs) 07:28, 5 May 2014 (UTC)


 * I get that now, but I wonder if there's a way to explain it in the page. Maybe not in a way that's worth the hassle though. Backfromquadrangle (discuss • contribs) 08:15, 6 May 2014 (UTC)


 * On being "worth the hassle", would it be simpler if we just shown the function with explicit binds alongside the do-block version? That might make things clear without needing a meticulous explanation.--Duplode (discuss • contribs) 12:54, 6 May 2014 (UTC)

Nondeterminism with the List monad
"For the list monad, non-determinism is present because different functions may return any number of different results when mapped over lists."

I found this sentence rather inaccurate and vague. What does it mean for non-determinism to be "present"? A program using the list monad is still a deterministic program, in the sense that every execution of the program would yield the same results. I guess what the author meant to say was, that the list monad can be used to *model* non-deterministic runs, by basically simulating all possible paths, when considering the (deterministic) return value of each function to be different alternatives for what the (modeled, non-deterministic) function would return. Corwin.amber (discuss • contribs) 04:30, 9 August 2016 (UTC)


 * That was indeed the intention of the original author. This meaning of "non-determinism" is well-established (cf., for an arbitrary example, Purely functional lazy nondeterministic programming by Sebastian Fischer et. al. A relevant quote from page 417: "To model nondeterministic computations in a pure functional language, the implicit computational effect of nondeterminism must be made explicit."). In any case, I agree the passage you quoted could be clearer --Duplode (discuss • contribs) 04:26, 15 November 2016 (UTC)