I hate monads.
I love 90% of Haskell. The functional stuff is beautiful, easy to understand, crystal clear, elegant, etc. But I'm having a mighty hard time getting my head around monads. Consider the following explanation of a monad: "A monad is represented as a type constructor (call it m), a function that builds values of that type (a -> m a), and a function that combines values of that type with computations that produce values of that type to produce a new computation for values of that type". 1) I know what a type is, but not a "type constructor". I don't normally think of an Int or even a complex type as being "constructed" except in the sense of OOP which I know is not what the author means. 2) Just *read* the paragraph... "a type constructor, a function that builds value of that type, and a function that combines values of that type with computations that produce values of that type to produce a computation of values of that type" Ugh.... Can anyone recommend a simple and clear explanation of monads? You can assume that I know basic math and basic Haskell syntax. So, for example, "a -> b" is much more clear than "a function that takes input of one type and has an output of a different type". Any help would be appreciated. Daniel. |
>>>>> "Daniel" == Daniel Carrera <[hidden email]> writes:
Daniel> Can anyone recommend a simple and clear explanation of Daniel> monads? You can assume that I know basic math and basic Daniel> Haskell syntax. So, for example, "a -> b" is much more Daniel> clear than "a function that takes input of one type and Daniel> has an output of a different type". This is excellent: http://ertes.de/articles/monads.html -- Colin Adams Preston Lancashire |
Colin Paul Adams wrote:
> This is excellent: > > http://ertes.de/articles/monads.html Thanks! I'll start reading that page immediately. Cheers, Daniel. |
In reply to this post by Daniel Carrera-4
Here's a clearer description:class Monad m where
return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b Instances of Monad must satisfy the following laws: return a >>= k == k a m >>= return == m m >>= (k >>= h) == (m >>= k) >>= h Much more clear and concise, don't you think? On Wed, Apr 22, 2009 at 6:21 AM, Daniel Carrera < [hidden email]> wrote: > I hate monads. > > I love 90% of Haskell. The functional stuff is beautiful, easy to > understand, crystal clear, elegant, etc. But I'm having a mighty hard time > getting my head around monads. Consider the following explanation of a > monad: > > "A monad is represented as a type constructor (call it m), a function that > builds values of that type (a -> m a), and a function that combines values > of that type with computations that produce values of that type to produce a > new computation for values of that type". > > 1) I know what a type is, but not a "type constructor". I don't normally > think of an Int or even a complex type as being "constructed" except in the > sense of OOP which I know is not what the author means. > > 2) Just *read* the paragraph... "a type constructor, a function that builds > value of that type, and a function that combines values of that type with > computations that produce values of that type to produce a computation of > values of that type" Ugh.... > > > Can anyone recommend a simple and clear explanation of monads? You can > assume that I know basic math and basic Haskell syntax. So, for example, "a > -> b" is much more clear than "a function that takes input of one type and > has an output of a different type". > > Any help would be appreciated. > > Daniel. > _______________________________________________ > Beginners mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/beginners > An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/beginners/attachments/20090422/8185017c/attachment-0001.htm |
In reply to this post by Daniel Carrera-4
Daniel Carrera wrote:
> Colin Paul Adams wrote: >> This is excellent: >> >> http://ertes.de/articles/monads.html > > Thanks! I'll start reading that page immediately. I noticed that this tutorial points to the following blog: http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ Wow! The author of this blog has nailed it. Trust me, I know, I was a math teacher for years (a *good* teacher, based on student reviews). The author of this blog is exactly right about why most tutorials about abstract concepts are no help (and why so many math teachers are bad). Now I'll go on to read the tutorial, encouraged that the author probably knows how to teach. Cheers, Daniel. |
In reply to this post by Daniel Carrera-4
2009/04/22 Daniel Carrera <[hidden email]>:
> I hate monads. Yikes! How do you feel about functors? > 1) I know what a type is, but not a "type constructor". I > don't normally think of an Int or even a complex type as being > "constructed" except in the sense of OOP which I know is not > what the author means. Well, an object constructor takes values and makes a value. A type constructor takes types and makes a type. You've probably seen a few type constructors in your life, for example, `std::vector`, which makes vectors of type `std::vector<t>`. Likewise, `std::map` is a two argument type constructor. > 2) Just *read* the paragraph... "a type constructor, a > function that builds value of that type, and a function that > combines values of that type with computations that produce > values of that type to produce a computation of values of that > type" ? Ugh.... I don't think you should take your first impression too seriously here. The notion of combining computations is really crucial to working with monads; you'll find it's pretty hard to get used to at first, no matter how it's presented. -- Jason Dusek |
In reply to this post by Colin Paul Adams
On 22 Apr 2009, at 12:26, Colin Paul Adams wrote: >>>>>> "Daniel" == Daniel Carrera <[hidden email]> writes: > > Daniel> Can anyone recommend a simple and clear explanation of > Daniel> monads? You can assume that I know basic math and basic > Daniel> Haskell syntax. So, for example, "a -> b" is much more > Daniel> clear than "a function that takes input of one type and > Daniel> has an output of a different type". > > This is excellent: > > http://ertes.de/articles/monads.html Hopefully this will help too - monads are made rather too much of, just build up slowly to them rather than diving into them first ? they're not the be all and end all of classes. http://noordering.wordpress.com/2009/03/31/how-you-shouldnt-use-monad/ Bob |
In reply to this post by Andrew Wagner
Andrew Wagner wrote:
> Here's a clearer description: > class Monad m where > return :: a -> m a > (>>=) :: m a -> (a -> m b) -> m b > > Instances of Monad must satisfy the following laws: > return a >>= k == k a > m >>= return == m > m >>= (k >>= h) == (m >>= k) >>= h > > Much more clear and concise, don't you think? Actually, that /is/ clearer for me. Though I still think I'll need the tutorial Colin gave me to gain better intuition and understand the motivations behind monads. That said, I do have questions: 1) Am I right in thinking that any type with two elements ("m a") is always a Monad? (IO String, Maybe Int, etc). 2) When I say "m a >>= f" the >>= just pulls the "a" out of "m a" and passes it to "f". Right? 3) The last two properties are not comparing values but functions. Right? For example, reading the second-last property: (m >>= return) :: a -> m a Where (m >>= return) is defined by (\x -> m x >>= return). Right? And this is why you can write the last property: (k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is what allows us to make (k >>= h) the second argument of ">>=" as in the last property: m >>= (k >>= h) == (m >>= k) >>= h Am I right? Thanks, Daniel. |
> 1) Am I right in thinking that any type with two elements ("m a") is always
> a Monad? (IO String, Maybe Int, etc). > > 2) When I say "m a >>= f" the >>= just pulls the "a" out of "m a" and passes > it to "f". Right? > > 3) The last two properties are not comparing values but functions. Right? > For example, reading the second-last property: > > (m >>= return) :: a -> m a > > Where (m >>= return) is defined by (\x -> m x >>= return). Right? And this > is why you can write the last property: > > (k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is what allows us to > make (k >>= h) the second argument of ">>=" as in the last property: > > m >>= (k >>= h) == (m >>= k) >>= h > > Am I right? I am also a beginner, so you should take my words with the grain of salt. Strange enough, the monad description that helped me most is the Wikipedia article: http://en.wikipedia.org/wiki/Monad_(functional_programming) This basically answers some of your questions by defining monad as triple (type constructor, bind function and return function), with certain properties. S. |
In reply to this post by Daniel Carrera-4
2009/04/22 Daniel Carrera <[hidden email]>:
> 1) Am I right in thinking that any type with two elements > ("m a") is always a Monad? (IO String, Maybe Int, etc). Well, no. Many such types are monads but not all of them. Monads have the monadic operations `return` and `>>=`. > 2) When I say "m a >>= f" the >>= just pulls the "a" out of "m > a" and passes it to "f". Right? Yes. The `>>=` operators defines our evaluation strategy; it allows us to combine computations. Be carefult of confusing `m` (a type constructor) with the value constructors for a particular monad. > 3) The last two properties are not comparing values but > functions. Right? For example, reading the second-last > property: > > (m >>= return) :: a -> m a Not quite -- `someMonadicValue >>= return` is of type `m a`. > Where (m >>= return) is defined by (\x -> m x >>= return). > Right? And this is why you can write the last property: > > (k >>= h) :: a -> h a defined by (\x -> k a >>= h) This is > what allows us to make (k >>= h) the second argument of ">>=" > as in the last property: Actually, the third law is: (m >>= f) >>= g = m >>= (\x -> f x >>= g) -- Jason Dusek |
In reply to this post by Daniel Carrera-4
On Wed, Apr 22, 2009 at 01:01:46PM +0200, Daniel Carrera wrote:
> Daniel Carrera wrote: >> Colin Paul Adams wrote: >>> This is excellent: >>> >>> http://ertes.de/articles/monads.html >> Thanks! I'll start reading that page immediately. > > I noticed that this tutorial points to the following blog: > > http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ > > Wow! The author of this blog has nailed it. Trust me, I know, I was a math > teacher for years (a *good* teacher, based on student reviews). The author > of this blog is exactly right about why most tutorials about abstract > concepts are no help (and why so many math teachers are bad). Thanks! =) You may also be interested in taking a look at the Typeclassopedia, in issue 13 of the Monad.Reader. http://haskell.org/haskellwiki/The_Monad.Reader -Brent |
In reply to this post by Jason Dusek
Jason Dusek wrote:
> Actually, the third law is: > > (m >>= f) >>= g == m >>= (\x -> f x >>= g) Yeah. I just saw that in the tutorial. And it actually makes more sense that way (esp after reading some of the tutorial): 1) A "computation" is something that may have a result. 2) In "m >>= f", m is a computation and f is a function that takes a value and returns a computation. >>= takes the output of m and makes it the input of f. 3) Therefore, the value of "m >>= f" is a computation. 4) Because "m >>= f" is a computation, it can be the left parameter of another >>=, as in "(m >>= f) >>= g". 5) If "x" is a value then "f x" is a computation. Thus, "f x" can be the left parameter of >>=, as in "f x >>= g", and the result of that is a computation. 6) Therefore, (\x -> f x >>= g) is a function that takes a value ("x") and returns a computation, so it can be the right parameter of >>=. I think I get it (at least this part). Cheers, Daniel. |
In reply to this post by Daniel Carrera-4
Daniel Carrera wrote:
> 1) I know what a type is, but not a "type constructor". I don't normally > think of an Int or even a complex type as being "constructed" except in > the sense of OOP which I know is not what the author means. [Int] is a type. [] itself is a type constructor, taking a type like Int and "constructing" a new type [Int] , a list of integers. In other words, a type constructor is like a function on types. Regards, apfelmus -- http://apfelmus.nfshost.com |
In reply to this post by Thomas Davie
> This is excellent:
> > http://ertes.de/articles/monads.html Wow. That really is a great tutorial! Suddenly the world becomes clear... Definitely gets my vote as must read material. Cheers, Sam |
Sam Martin wrote:
>> This is excellent: >> >> http://ertes.de/articles/monads.html > > Wow. That really is a great tutorial! Suddenly the world becomes > clear... > > Definitely gets my vote as must read material. +1 I was very impressed too. And I am not easy to impress when it comes to documentation. I plan to read it a second time to solidify some of the ideas, but on my first reading my understanding of Monads increased by leaps and bounds. Ertugrul deserves to be commended, and this tutorial should be made more prominent on haskell.org. Daniel. |
>>>>> "Daniel" == Daniel Carrera <[hidden email]> writes:
Daniel> Sam Martin wrote: >>> This is excellent: >>> >>> http://ertes.de/articles/monads.html >> >> Wow. That really is a great tutorial! Suddenly the world >> becomes clear... >> >> Definitely gets my vote as must read material. Daniel> +1 Daniel> I was very impressed too. And I am not easy to impress Daniel> when it comes to documentation. I plan to read it a second Daniel> time to solidify some of the ideas, but on my first Daniel> reading my understanding of Monads increased by leaps and Daniel> bounds. Daniel> Ertugrul deserves to be commended, and this tutorial Daniel> should be made more prominent on haskell.org. I think so. I've read VERY MANY tutorials on monads, and they were all confusing - except this one. -- Colin Adams Preston Lancashire |
Hello people,
thanks for all your positive comments about my tutorial, both here and through direct email. I appreciate that very much. =) I'm glad that my work is helpful to the community. Greets, Ertugrul. Colin Paul Adams <[hidden email]> wrote: > >>>>> "Daniel" == Daniel Carrera <[hidden email]> writes: > > Daniel> Sam Martin wrote: > >>> This is excellent: > >>> > >>> http://ertes.de/articles/monads.html > >> > >> Wow. That really is a great tutorial! Suddenly the world > >> becomes clear... > >> > >> Definitely gets my vote as must read material. > > Daniel> +1 > > Daniel> I was very impressed too. And I am not easy to impress > Daniel> when it comes to documentation. I plan to read it a second > Daniel> time to solidify some of the ideas, but on my first > Daniel> reading my understanding of Monads increased by leaps and > Daniel> bounds. > > Daniel> Ertugrul deserves to be commended, and this tutorial > Daniel> should be made more prominent on haskell.org. > > I think so. > I've read VERY MANY tutorials on monads, and they were all confusing - > except this one. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ |
On Thu, Apr 23, 2009 at 09:42:56PM +0200, Ertugrul Soeylemez wrote:
> Hello people, > > thanks for all your positive comments about my tutorial, both here and > through direct email. I appreciate that very much. =) > > I'm glad that my work is helpful to the community. Would you provide a PDF version along with the HTML version? Regards, Romildo > Colin Paul Adams <[hidden email]> wrote: > > > >>>>> "Daniel" == Daniel Carrera <[hidden email]> writes: > > > > Daniel> Sam Martin wrote: > > >>> This is excellent: > > >>> > > >>> http://ertes.de/articles/monads.html > > >> > > >> Wow. That really is a great tutorial! Suddenly the world > > >> becomes clear... > > >> > > >> Definitely gets my vote as must read material. > > > > Daniel> +1 > > > > Daniel> I was very impressed too. And I am not easy to impress > > Daniel> when it comes to documentation. I plan to read it a second > > Daniel> time to solidify some of the ideas, but on my first > > Daniel> reading my understanding of Monads increased by leaps and > > Daniel> bounds. > > > > Daniel> Ertugrul deserves to be commended, and this tutorial > > Daniel> should be made more prominent on haskell.org. > > > > I think so. > > I've read VERY MANY tutorials on monads, and they were all confusing - > > except this one. |
[hidden email] wrote:
> > thanks for all your positive comments about my tutorial, both here > > and through direct email. I appreciate that very much. =) > > > > I'm glad that my work is helpful to the community. > > Would you provide a PDF version along with the HTML version? That will require me to write another XSLT stylesheet, something which I was going to do anyway, but haven't done yet. If you would like to convert it yourself, you'll find the original source files here: * http://ertes.de/articles/monads.xml * http://ertes.de/articles/Article.xsl * http://ertes.de/articles/Article.rng Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/ |
While i agree to some extent that analogies are bad in some sense , i found
this one really insightful when i was trying to put my head around monads : http://www.haroldtherebel.com/2007/12/02/monads-and-schroedingers-cat/ what do u guys think ? On Fri, Apr 24, 2009 at 11:18 AM, Ertugrul Soeylemez <[hidden email]> wrote: > [hidden email] wrote: > > > > thanks for all your positive comments about my tutorial, both here > > > and through direct email. I appreciate that very much. =) > > > > > > I'm glad that my work is helpful to the community. > > > > Would you provide a PDF version along with the HTML version? > > That will require me to write another XSLT stylesheet, something which I > was going to do anyway, but haven't done yet. If you would like to > convert it yourself, you'll find the original source files here: > > * http://ertes.de/articles/monads.xml > * http://ertes.de/articles/Article.xsl > * http://ertes.de/articles/Article.rng > > > Greets, > Ertugrul. > > > -- > nightmare = unsafePerformIO (getWrongWife >>= sex) > http://blog.ertes.de/ > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/beginners > -- Federico Brubacher www.fbrubacher.com Colonial Duty Free Shop www.colonial.com.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/beginners/attachments/20090424/8b0b91e8/attachment.htm |
Free forum by Nabble | Edit this page |