5 ms·

Do haskell people realize that using haskell describe monads isn't actually helpful?

orbifold 12y ago
Well you could explain them in terms of category theory as an endofunctor T: C -> C, together with two natural transformations eta : 1 -> T and mu : T^2 -> T, that satisfy a number of axioms. The Haskell definition encodes a special case, where the underlying "category" is "Hask", whose objects are Haskell types and morphisms are Haskell terms. Of course this is strictly speaking not a category, but it is close enough. In mathematics monads usually arise as adjunctions between two functors, for example beginning with a set of elements, you can consider the free monoid generated by it and forget the group structure, this gives you a much larger set. If you did this operation on a set of characters, you would get the set of all strings of those characters, eta would in this case be the operation that given a character in the character set gives you the corresponding string of length one and mu would concatenate two strings.
- recursive 12y ago
  That's maybe helpful for mathemticians.
- corysama 12y ago
  Unfortunately, you've taken it two steps in the opposite direction from helpful. The point is that when your audience is neither haskellers nor mathematicians (I.e. the vast majority of programmers on Earth) repeatedly explaining monads in Haskell and/or mathematics is not helpful. Imagine if you wanted to learn about monads, but every article went "Monads are a simple and powerful idea that, interestingly enough, can be very, very well expressed in Latin. Therefore, I will switch to Latin for the remainder of this article. Oh... You haven't studied Latin? You really should! It's really very useful. Moving on... Cogitus sin extricatus..." If you want your audience to understand, you need to explain it in C.
  - freyrs3 12y ago
    C is probably the worst language to implement monads in because the type systems really lacks polymorphism, higher order functions and any sort of type-class overloading to clean up the syntax. I mean you could hypothetically pass around a record full of void function pointers to get around all this, but it would be so ugly and unintuitive that it would be silly to try and explain monads this way.
    - dllthomas 12y ago
      Actually, you can do a bit more than that if you specialize. It'll still be ugly, but it might help people grasp what's going on.
      - corysama 12y ago
        I think you have the same idea I do. In a statically compiled language, all of the high order polymorphism eventually compiles down to actual, concrete code that should be expressible in hand-specialized C structs and functions performing a single, specific task. Haskell makes that specialization process incredibly convenient and C makes it incredibly inconvenient. But, the point is not to ship a bunch of production code quickly. The point is to provide a low-abstraction example to demonstrate concretely what the compiler is doing for you without prefacing the example with "Assuming of course that you have already studied Haskell..."
        freyrs3 12y ago
        You'd end up building a small functional runtime. That's a fun project to understand compilers better. But given that Haskell types are erased at runtime the very thing that makes monads monads wouldn't even be around anymore. All the values would be represented uniformly by some *StgClosure struct and the whole program would just be a mess of casts and projections into these values.
        dllthomas 12y ago
- ghkbrew 12y ago
  I'll just leave this here: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem http://stackoverflow.com/questions/3870088/a-monad-is-just-a...
- sampo 12y ago
  Seriously, man! Anybody who would understand your explanation is the kind of person who already knows what monads are, and thus does not need your explanation in the first place.
dons 12y ago
Psuedocode then. Given a type `m` and a type `a` a monad provides functions with types: bind : m a → (a → m b) → m b wrap : a → m a
tel 12y ago
You need a language which enables generalization. Sadly, most computer languages lack good facilities for this. Human language works, though: A monad is some parametric type, T, along with two functions called (in Haskell anyway) "return" and "bind". Return "injects" values into the type taking values of type A to values of type T(A). Bind transforms values of type T(A) into values of type T(B) using a function like A -> T(B). Then these two functions must follow a few rules. That's a monad. The Haskell fragment above describes the signatures of those functions, notes how they relate to the parametric type, and also produces a facility for overloading `return` and `(>>=)` ("bind") and even working with them when lacking a concrete choice of type `T`.
- freyrs3 12y ago
  I try to put myself in the mind of someone who works in a language in which type notions like ( t : * -> * ) and ( a -> t b ) are completely inexpressible I can see how it can be hard to wrap your head around monads. I think a lot of the communication problem about monads is fundamentally a problem that higher types and parametric polymorphism are just not part of the general programmer knowledge and there's no reference point to understand the signatures.
  - tel 12y ago
    Yeah, agreed. I would add to that list general confusion around what "monad" is: is it a noun, an adjective, what kind of noun? Can I touch it, build it, program it? How many are there? All of those questions change their answer depending, terrifyingly, on how you informally define the word "monad".
    - dllthomas 12y ago
      Just today I've been playing with an alternate prelude that I think makes all this a bit clearer (at the cost of using basically every GHC extension, ironically).

Well you could explain them in terms of category theory as an endofunctor T: C -> C, together with two natural transformations eta : 1 -> T and mu : T^2 -> T, that satisfy a number of axioms. The Haskell definition encodes a special case, where the underlying "category" is "Hask", whose objects are Haskell types and morphisms are Haskell terms. Of course this is strictly speaking not a category, but it is close enough. In mathematics monads usually arise as adjunctions between two functors, for example beginning with a set of elements, you can consider the free monoid generated by it and forget the group structure, this gives you a much larger set. If you did this operation on a set of characters, you would get the set of all strings of those characters, eta would in this case be the operation that given a character in the character set gives you the corresponding string of length one and mu would concatenate two strings.

recursive 12y ago
That's maybe helpful for mathemticians.
corysama 12y ago
Unfortunately, you've taken it two steps in the opposite direction from helpful. The point is that when your audience is neither haskellers nor mathematicians (I.e. the vast majority of programmers on Earth) repeatedly explaining monads in Haskell and/or mathematics is not helpful. Imagine if you wanted to learn about monads, but every article went "Monads are a simple and powerful idea that, interestingly enough, can be very, very well expressed in Latin. Therefore, I will switch to Latin for the remainder of this article. Oh... You haven't studied Latin? You really should! It's really very useful. Moving on... Cogitus sin extricatus..." If you want your audience to understand, you need to explain it in C.
- freyrs3 12y ago
  C is probably the worst language to implement monads in because the type systems really lacks polymorphism, higher order functions and any sort of type-class overloading to clean up the syntax. I mean you could hypothetically pass around a record full of void function pointers to get around all this, but it would be so ugly and unintuitive that it would be silly to try and explain monads this way.
  - dllthomas 12y ago
    Actually, you can do a bit more than that if you specialize. It'll still be ugly, but it might help people grasp what's going on.
    - corysama 12y ago
      I think you have the same idea I do. In a statically compiled language, all of the high order polymorphism eventually compiles down to actual, concrete code that should be expressible in hand-specialized C structs and functions performing a single, specific task. Haskell makes that specialization process incredibly convenient and C makes it incredibly inconvenient. But, the point is not to ship a bunch of production code quickly. The point is to provide a low-abstraction example to demonstrate concretely what the compiler is doing for you without prefacing the example with "Assuming of course that you have already studied Haskell..."
      - freyrs3 12y ago
        You'd end up building a small functional runtime. That's a fun project to understand compilers better. But given that Haskell types are erased at runtime the very thing that makes monads monads wouldn't even be around anymore. All the values would be represented uniformly by some *StgClosure struct and the whole program would just be a mess of casts and projections into these values.
        dllthomas 12y ago
ghkbrew 12y ago
I'll just leave this here: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem http://stackoverflow.com/questions/3870088/a-monad-is-just-a...
sampo 12y ago
Seriously, man! Anybody who would understand your explanation is the kind of person who already knows what monads are, and thus does not need your explanation in the first place.

dons 12y ago

Psuedocode then. Given a type `m` and a type `a` a monad provides functions with types: bind : m a → (a → m b) → m b wrap : a → m a

tel 12y ago

You need a language which enables generalization. Sadly, most computer languages lack good facilities for this. Human language works, though: A monad is some parametric type, T, along with two functions called (in Haskell anyway) "return" and "bind". Return "injects" values into the type taking values of type A to values of type T(A). Bind transforms values of type T(A) into values of type T(B) using a function like A -> T(B). Then these two functions must follow a few rules. That's a monad. The Haskell fragment above describes the signatures of those functions, notes how they relate to the parametric type, and also produces a facility for overloading `return` and `(>>=)` ("bind") and even working with them when lacking a concrete choice of type `T`.

freyrs3 12y ago
I try to put myself in the mind of someone who works in a language in which type notions like ( t : * -> * ) and ( a -> t b ) are completely inexpressible I can see how it can be hard to wrap your head around monads. I think a lot of the communication problem about monads is fundamentally a problem that higher types and parametric polymorphism are just not part of the general programmer knowledge and there's no reference point to understand the signatures.
- tel 12y ago
  Yeah, agreed. I would add to that list general confusion around what "monad" is: is it a noun, an adjective, what kind of noun? Can I touch it, build it, program it? How many are there? All of those questions change their answer depending, terrifyingly, on how you informally define the word "monad".
  - dllthomas 12y ago
    Just today I've been playing with an alternate prelude that I think makes all this a bit clearer (at the cost of using basically every GHC extension, ironically).