tag:blogger.com,1999:blog-1228698015266547737.post7333983423401888720..comments2023-07-28T01:27:33.228-07:00Comments on Computational Thoughts: Learning Monads in 1996Josefhttp://www.blogger.com/profile/13272830598221833253noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1228698015266547737.post-71631683189146557312007-11-30T03:15:00.000-08:002007-11-30T03:15:00.000-08:00Great article. And I just wanted to say thanks to...Great article. And I just wanted to say thanks to José for his comment too. I've worked with Haskell and am comfortable with functional programming, but I still had not grokked monads, and José's insight about not _wanting_ to create them really hit home for me. Thank you for that.Anonymoushttps://www.blogger.com/profile/15788549323002567321noreply@blogger.comtag:blogger.com,1999:blog-1228698015266547737.post-72677080890976526042007-11-29T06:51:00.000-08:002007-11-29T06:51:00.000-08:00I followed your path plus tutorials. I have my "Ok...I followed your path plus tutorials. I have my "Ok, I understand the definition. But what *is* a monad?" moment too. <BR/><BR/>Mathematical definition is almost useless for a programmer, I still wanted to know when and where should I create my own monads. I can agree with Marceau that the best way for a programmer to understand monads is following the monoid/functor way.<BR/><BR/>Then I realized it... A monad is not something I "want" to create, it is something the program itself impose to me. I have my types a, b, c and a lot of functions over them. Then I need a type constructor D, and suddenly I have D a, D b, D c and all my old functions are useless on the new types. And is in this stage that super monad comes to rescue: I implement bind and return on D, and voila! I get my old functions working in my new types.Anonymoushttps://www.blogger.com/profile/15730779978022115418noreply@blogger.comtag:blogger.com,1999:blog-1228698015266547737.post-58330773638429450702007-11-28T15:28:00.000-08:002007-11-28T15:28:00.000-08:00On the other hand, mathematicians have understood ...On the other hand, mathematicians have understood monads for decades. The list monad is just a functor L from Sets to Sets (or Monoids if you prefer) such that there is a multiplication map (natural transformation) mu: L L X -> L X given by concatenation and an identity map nu: X -> L X taking an element x to a list with one element [x]. This forms a monoid in the category of endofunctors over Set and was called a triple for years before the word monad was invented.<BR/><BR/>Monads for programmers take a formally different, less familiar, but nevertheless equivalent form: the map nu is called return and a map called bind is used instead of mu, where bind f x can be defined as join ( fmap f x). (Join can be given by join x = bind id x.) This approach is more difficult to understand because it obscures the more familiar underlying structure of a monoid, of which we are intimately acquainted with: addition and multiplication of integers, rationals, reals; compositions of functions; etc. Even the bind approach is well understood mathematically as the Kleisli category of a monoid -- a way of factoring a monad into a pair of adjoint functors (of which there are in general many). <BR/><BR/>Monads are still taught the wrong way (nuclear waste containers!?) today by nearly everyone and as such have continued to be a barrier to understanding Haskell and functional programming. Monoids are much easier to understand (concatenation versus bind for instance) and the cost is only one more definition, that of bind in terms of join.Marchttps://www.blogger.com/profile/15592403424673133194noreply@blogger.com