5 ms·

Haskell's Monad is a very, very special case of the mathematical monad. The problem with Stephen Diehl's approach is that it treats the topic in full generali

by tome 13y ago

Haskell's Monad is a very, very special case of the mathematical monad. The problem with Stephen Diehl's approach is that it treats the topic in full generality making it much harder to understand how the special case is actually much simpler. I prefer http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-is-a-monad-really.html http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-i..., but that's probably because I wrote it.

effn 13y ago
I think this is for people that already know how to use monads effectively in Haskell and wants to learn more about the mathematical background.
- freyrs3 13y ago
  This is explicitly not a writeup for beginners ( ergo the title ), it's a side-by-side description of the /very/ general categorical description and how you can model that in Haskell. The three parameter form of morphism composition ( i.e. c y z -> c x y -> c x z ) would be quite unwieldy in day-to-day programming but it does illustrate the underlying definitions better to have categories explicit.
  - trobertson 13y ago
    I don't mean to nitpick, but the three parameter form is exactly what you use in day-to-day Haskell programming. You simply let c be the infix (->), and you get (y -> z) -> (x -> y) -> (x -> z). We just tend to think of it as a two parameter form because a lot of the time, you can think of (->) as syntax, as opposed to the type that it is.
    - lelf 13y ago
      Yup. This is straight cut from Control.Category module: instance Category (->) where id = Prelude.id (.) = (Prelude..)
- tome 13y ago
  That's pretty much my point: I don't think mathematical monads are a good background for Haskell Monads. It's a bit like saying the ZF axioms are the mathematical background for Data.Set.
- jfarmer 13y ago
  It's great for two classes of people: those who understand monads from a Haskell/software engineering perspective and want to learn the mathematical perspective, and those like me who understand them from the mathematical perspective and want to learn them from the Haskell/software engineering perspective. Given that, I think it's great! :D
rwosync 13y ago
This is a post about categorical monads, I assume this is why it doesn't use the standard symbols that the Haskell monad uses (>>=, return) and instead refers to the natural transformations (η, μ) as mathematicians do. [1] http://ncatlab.org/nlab/show/monad#definition_18 http://ncatlab.org/nlab/show/monad#definition_18
tel 13y ago
Understanding the very generalized algebraic monad helps you to understand the nature of encapsulating effects and adding complexity to categories through layering. It's absolutely not beginner material—but it's valuable material. I don't like your take because it refuses to take that deeper dive into the mathematical Monad, despite [alluding] to it. Knowing the relationship between `Monad` and `Category` the type classes is almost never useful in programming Haskell. Knowing the relationship between `Monad`, monads, and their categorical underpinning is a different matter.
- tome 13y ago
  > Understanding the very generalized algebraic monad helps you to understand the nature of encapsulating effects and adding complexity to categories through layering. I don't see how the general notion of category theoretical monad helps with this. In fact it's debatable whether the notion of monad is really the right treatment for universal algebra at all. Lawvere theories are much simpler and capture almost all of what you need. See: https://www.dpmms.cam.ac.uk/~martin/Research/Publications/2007/hp07.pdf https://www.dpmms.cam.ac.uk/~martin/Research/Publications/20... > Knowing the relationship between `Monad` and `Category` the type classes is almost never useful in programming Haskell. I disagree. I use (<=<) all the time. It's basically (.) with the Kleisli wrapping and unwrapping done for you.
  - tel 13y ago
    I'm not arguing that (>=>) isn't great or that Monads are better than Lawvere Theories, nor that what you presented isn't interesting and useful. Instead, I'm responding from the point of view of someone who read a lot of terse accounts of what typeclass Monads were back when I was first learning them. The category law account for the Monad laws is useful once you've already learned to think categorically, at which point a full definition is great and provides indications of the next places to examine. Defining that a "Monad is really a Category k with an identification between k a b and a -> k () b" seems most useful to people who could already write "Monads Made Difficult", but not those who are trying to struggle to see how all these connections play out. Monads Made Difficult is difficult, but lays the groundwork for a lot of the categorical machinery that forms the environment where Monads were born. That's important.
nbouscal 13y ago
That's not a problem with Stephen's approach, that's simply what he was writing about. I found it to be a great concise presentation. Your post and his post have different goals, that does not make either one better than the other.
tome 13y ago
To all those who are replying to me that I have misinterpreted this as beginner material, well the first sentence does say that it's an "introduction to Haskell monads".
- nbouscal 13y ago
  No, the first sentence says that it’s an “introduction to Haskell monads derived from a categorical perspective.” Big difference.
jfarmer 13y ago
As a counterpoint, I'm fluent in mathematics but know virtually no Haskell. Your write up presumes the exact opposite and is therefore totally unsuitable for someone like me. :) I mean that quite literally: I can make neither heads nor tails of your write up. It looks like a bunch of text with funny characters to me. This write up, OTOH, is written in my language using idioms I understand and relates it to Haskell without involving too much of the machinery of the language.
- reeses 13y ago
  This is precisely what made Haskell's monads difficult for me to understand. I kept trying to fit the square block in the round hole. I finally had to divorce the terms in my head, much like watching the film version of a book that I have read. They are..."related" but frustration will result from assuming they will be the same.
  - jfarmer 13y ago
    Nice! Yeah. I had two avenues of understanding available to me when it came to monads. The first was my knowledge as a mathematically-inclined software engineer. The second was my knowledge as someone fluent in high-level mathematics. I'll say, here was one key to my understanding once I saw it. In a purely functional language you want everything to be referentially transparent. That is, an expression should be able to be substituted for its value at any given moment in time. At the very least, you'll want the ability to denote which parts of your program are referentially transparent and which aren't. This can be expressed as utopian vision: in a purely functional language we'd like everything -- everything -- to be a value. We now need some way of translating code with side effects into code that returns a value. The logical abstraction is to say that the "value" is not the work itself -- once the work is done it's out of the bag, after all -- but rather the "value" is the machine which can perform that work. To a mathematician this screams "functor." If you want to move between the two spaces repeatedly this screams "adjoint functors." There's some work you want to do in Space A that's more easily expressed in Space B, so you take a thing in A, transform it to a thing in B, do the work in B, and then transform back to A. Think in, e.g., Ruby: sentence.split(' ').map(&:reverse).join(' ') split(' ') and join(' ') aren't quite inverses of each other, but they are adjoint. These pairs take us from the land of space-separated strings to the land of arrays back to the land of space separated strings. You see that all the time in programming and mathematics. I sometimes call it the "Super Mario Brothers" maneuver when I'm trying to teach it to students. Mario wants to get to the end of the level, so he hits a block, goes up the vine to cloud land, runs through cloud land, and then comes back down.
dasil003 13y ago
> The problem [...] is that [...] making it much harder [...] But the title of the article is "Monads made difficult", so I don't understand why you think this is a problem.

by tome 13y ago

effn 13y ago

I think this is for people that already know how to use monads effectively in Haskell and wants to learn more about the mathematical background.

freyrs3 13y ago
This is explicitly not a writeup for beginners ( ergo the title ), it's a side-by-side description of the /very/ general categorical description and how you can model that in Haskell. The three parameter form of morphism composition ( i.e. c y z -> c x y -> c x z ) would be quite unwieldy in day-to-day programming but it does illustrate the underlying definitions better to have categories explicit.
- trobertson 13y ago
  I don't mean to nitpick, but the three parameter form is exactly what you use in day-to-day Haskell programming. You simply let c be the infix (->), and you get (y -> z) -> (x -> y) -> (x -> z). We just tend to think of it as a two parameter form because a lot of the time, you can think of (->) as syntax, as opposed to the type that it is.
  - lelf 13y ago
    Yup. This is straight cut from Control.Category module: instance Category (->) where id = Prelude.id (.) = (Prelude..)
tome 13y ago
That's pretty much my point: I don't think mathematical monads are a good background for Haskell Monads. It's a bit like saying the ZF axioms are the mathematical background for Data.Set.
jfarmer 13y ago
It's great for two classes of people: those who understand monads from a Haskell/software engineering perspective and want to learn the mathematical perspective, and those like me who understand them from the mathematical perspective and want to learn them from the Haskell/software engineering perspective. Given that, I think it's great! :D

rwosync 13y ago

This is a post about categorical monads, I assume this is why it doesn't use the standard symbols that the Haskell monad uses (>>=, return) and instead refers to the natural transformations (η, μ) as mathematicians do. [1] http://ncatlab.org/nlab/show/monad#definition_18 http://ncatlab.org/nlab/show/monad#definition_18

tel 13y ago

Understanding the very generalized algebraic monad helps you to understand the nature of encapsulating effects and adding complexity to categories through layering. It's absolutely not beginner material—but it's valuable material. I don't like your take because it refuses to take that deeper dive into the mathematical Monad, despite [alluding] to it. Knowing the relationship between `Monad` and `Category` the type classes is almost never useful in programming Haskell. Knowing the relationship between `Monad`, monads, and their categorical underpinning is a different matter.

tome 13y ago
> Understanding the very generalized algebraic monad helps you to understand the nature of encapsulating effects and adding complexity to categories through layering. I don't see how the general notion of category theoretical monad helps with this. In fact it's debatable whether the notion of monad is really the right treatment for universal algebra at all. Lawvere theories are much simpler and capture almost all of what you need. See: https://www.dpmms.cam.ac.uk/~martin/Research/Publications/2007/hp07.pdf https://www.dpmms.cam.ac.uk/~martin/Research/Publications/20... > Knowing the relationship between `Monad` and `Category` the type classes is almost never useful in programming Haskell. I disagree. I use (<=<) all the time. It's basically (.) with the Kleisli wrapping and unwrapping done for you.
- tel 13y ago
  I'm not arguing that (>=>) isn't great or that Monads are better than Lawvere Theories, nor that what you presented isn't interesting and useful. Instead, I'm responding from the point of view of someone who read a lot of terse accounts of what typeclass Monads were back when I was first learning them. The category law account for the Monad laws is useful once you've already learned to think categorically, at which point a full definition is great and provides indications of the next places to examine. Defining that a "Monad is really a Category k with an identification between k a b and a -> k () b" seems most useful to people who could already write "Monads Made Difficult", but not those who are trying to struggle to see how all these connections play out. Monads Made Difficult is difficult, but lays the groundwork for a lot of the categorical machinery that forms the environment where Monads were born. That's important.

nbouscal 13y ago

That's not a problem with Stephen's approach, that's simply what he was writing about. I found it to be a great concise presentation. Your post and his post have different goals, that does not make either one better than the other.

tome 13y ago

To all those who are replying to me that I have misinterpreted this as beginner material, well the first sentence does say that it's an "introduction to Haskell monads".

nbouscal 13y ago
No, the first sentence says that it’s an “introduction to Haskell monads derived from a categorical perspective.” Big difference.

jfarmer 13y ago

As a counterpoint, I'm fluent in mathematics but know virtually no Haskell. Your write up presumes the exact opposite and is therefore totally unsuitable for someone like me. :) I mean that quite literally: I can make neither heads nor tails of your write up. It looks like a bunch of text with funny characters to me. This write up, OTOH, is written in my language using idioms I understand and relates it to Haskell without involving too much of the machinery of the language.

reeses 13y ago
This is precisely what made Haskell's monads difficult for me to understand. I kept trying to fit the square block in the round hole. I finally had to divorce the terms in my head, much like watching the film version of a book that I have read. They are..."related" but frustration will result from assuming they will be the same.
- jfarmer 13y ago
  Nice! Yeah. I had two avenues of understanding available to me when it came to monads. The first was my knowledge as a mathematically-inclined software engineer. The second was my knowledge as someone fluent in high-level mathematics. I'll say, here was one key to my understanding once I saw it. In a purely functional language you want everything to be referentially transparent. That is, an expression should be able to be substituted for its value at any given moment in time. At the very least, you'll want the ability to denote which parts of your program are referentially transparent and which aren't. This can be expressed as utopian vision: in a purely functional language we'd like everything -- everything -- to be a value. We now need some way of translating code with side effects into code that returns a value. The logical abstraction is to say that the "value" is not the work itself -- once the work is done it's out of the bag, after all -- but rather the "value" is the machine which can perform that work. To a mathematician this screams "functor." If you want to move between the two spaces repeatedly this screams "adjoint functors." There's some work you want to do in Space A that's more easily expressed in Space B, so you take a thing in A, transform it to a thing in B, do the work in B, and then transform back to A. Think in, e.g., Ruby: sentence.split(' ').map(&:reverse).join(' ') split(' ') and join(' ') aren't quite inverses of each other, but they are adjoint. These pairs take us from the land of space-separated strings to the land of arrays back to the land of space separated strings. You see that all the time in programming and mathematics. I sometimes call it the "Super Mario Brothers" maneuver when I'm trying to teach it to students. Mario wants to get to the end of the level, so he hits a block, goes up the vine to cloud land, runs through cloud land, and then comes back down.

dasil003 13y ago

> The problem [...] is that [...] making it much harder [...] But the title of the article is "Monads made difficult", so I don't understand why you think this is a problem.