7 ms·

I disagree completely with his analysis on monads. If you just present the abstract structure, you cannot understand why you even want (for example) the do not

by rtpg 14y ago

I disagree completely with his analysis on monads. If you just present the abstract structure, you cannot understand why you even want (for example) the do notation as a language-level concept. I think this is more of a case of bad examples than anything. Trying to represnent monads via analogy works badly too though, because monads as used in haskell are more about programming pragmatics than modelling real world objects. The way to explain it should be : - Show real code - Explain why we use this structure to write our code .I think a good explanation is to ... in Jquery you do things like chaining to build things. $('selector').css('color','red').filter(someFilter).css('color','blue') Chaining APIs are useful because you're combining computation('chaining'), and you don't want to have to carry around a value everywhere. You want to do the same thing in Haskell obviously. Haskell doesn't have dot notation, so you can't do this style exactly. First idea would be to do something like let x=jQuery document selector in let y=css x 'color' 'red' in let z=filter y someFilter in ... This is a pain, especially considering that the 'chaining' here is mechanically obvious let [n+1] = f [n] [whatever] in let [n+2] = g [n+1] .... So monads, in the most pragmatic sense, allow you to represnt this form of computation. You end up with jQuery 'selector' >>= css 'color' 'red' >>= filter someSelector >>= css 'color' blue' You implicitly carry around your computation. ) In any case the Maybe monad is the worst example ever, just like how a singleton group is a bad example. Sure it's the 'simplest' , but it's far from the most typical

freyrs3 14y ago
The problem with bringing jQuery into the discussion is that it's not a monad. Don Stewart explains this more elegantly than I can [1] but the crux of the argument is that chaining together computations is not enough to be a monad, one needs to prove that the monad laws hold. [1] http://stackoverflow.com/questions/10496932/is-jquery-a-monad/10499668#10499668 http://stackoverflow.com/questions/10496932/is-jquery-a-mona...
- sordina 14y ago
  The majority of the 'proofs' I've seen that jQuery isn't a monad seem to either be probabalistic, or use the "Burden of Proof" argument to show that since nobody has proved that jQuery is a monad, we should assume that it isn't. I agree that jQuery probably isn't a monad, but it rubs me the wrong way that people aren't willing to say "It has yet to be determined if jQuery is a monad". Obviously it is trivial to show that it isn't a monad by the fact that javascript permits any action in pure code, but by the same token, unsafePerformIO proves that Haskell has no monads. I think it's fair to operate under a reasonable subset of jQuery functionality when asking the question.
  - xyzzyz 14y ago
    The point is that the concept of monad is a very concrete thing. Monad is not "chaining operations". Monad is not "returning actions instead of values". Monad is not some vague concept. If JQuery is a monad, what are the monadic operations that make it a monad? What are its equivalents of return and bind (or any other equivalent definitions of a monad)? It's not a tricky question. Saying that JQuery is a monad without saying what its return and bind are is equivalent to saying that whistling is Turing complete without saying how you can compute stuff with whistling. The problem here is not whether whistling is Turing complete or not, the problem is what it would even mean for whistling to be Turing complete. This means that as of now, as long as you don't tell us what are the monadic operations of JQuery, it cannot be determined whether JQuery is a monad, because this question does not make sense yet.
    - jes5199 14y ago
      JQuery is an implementation of the List monad.
      - tome 14y ago
        JQuery is an enormous API, so it is implausible that it is an implementation of the list monad. Some aspect of it might be the list monad. If so, which?
        jes5199 14y ago
        Most jQuery methods are functions that are mapped over a collection of elements. Many verbs return collections themselves, which are concatted together into the resulting collection. That's analogous to how List works. So $(element) implements return as a -> [a] And bind is mapcat, which is called by most of the jQuery methods. Yes, that's a subset of the API, but it's the subset that distinguishes jQuery from any other collection of helper functions.
        nbouscal 14y ago
tome 14y ago
Maybe is not the simplest monad, Identity is, and I think Maybe is an excellent example of a monad.
- TheCoelacanth 14y ago
  Identity is simpler, but it's not very interesting. It's hard for a beginner to see why you would ever use the Identity monad. Maybe is the simplest interesting monad, which makes it a good candidate for explaining monads to beginners.
sordina 14y ago
I'm not sure you actually disagree with his method of learning monads. He primarily advocates for avoiding the use of analogies, which you seem to agree with. He advocates using concrete monads in real code, which you also seem to agree with. The only contentious point might be learning typeclasses and how monads fit into the Typeclassopedia. If you want to be able to trace how your monad-using code is evaluated this is a necessity. Like it or not. Also, attacking monads from both the concrete and the abstract at the same time seems to be a good approach, with satori being achieved once the understandings meet. A dynamic-programming approach? You may possibly be disagreeing with the order in which he lists these components of learning in his 'Eightfold Path', but if the analogy to the Buddhist teachings is followed further, then the steps need not be taken in sequence. The slides certainly include many monad examples besides maybe at any rate. I think the slides are worth another look :)
kzrdude 14y ago
Your pipeline example looks more fit for simple function composition. f = filter (\x color x == BlueColor) . select (\x color x == RedColor)
- jes5199 14y ago
  That's true for this example, but when you do tree walking stuff in jQuery (like elements.children().children() ) then you have to think of it as a concatting map instead as just a regular map or filter
lmm 14y ago
Agree 100% on just showing the real code. Don't tell me what a monad is, tell me a problem I can solve with it. (I've made my own attempt at http://m50d.github.io/2013/01/16/generic-contexts.html http://m50d.github.io/2013/01/16/generic-contexts.html )
marshray 14y ago
I've read lots of monad tutorials. I get it, they're a way of encapsulating side-effects in a pure lazy language. But Haskell doesn't sink in unless I use on a regular basis. The time that I've felt like I was able to see a light at the end of the tunnel (i.e., that I might be able to be useful enough in Haskell that I could keep using it regularly) was when I simply memorized the expansions for the do, <-, return sugars.
- chowells 14y ago
  You've just proved that the monad tutorials you've read are useless. Monads are emphatically not "a way of encapsulating side-effects in a pure lazy language". Haskell's IO type is a way of encapsulating side effects in a pure lazy language. Haskell's IO type happens to form a monad. The fact that it forms a monad is completely irrelevant to what it actually does. Forming a monad is a very abstract consideration. It has to do with the data type supporting a couple operations with specific properties. It doesn't say a thing about what those operations mean, so long as the required properties hold. It's up to specific monads to insert semantics into those operations. And so yes, the IO type specifies that its monad operations mean "creating a trivial IO action that gives a specific value when executed" and "feed the result of executing an IO action into a function that returns another action." And that turns out to be a sufficient framework for composing IO actions together, once something else is providing them. But IO isn't the only monad. There are hundreds of others already defined, and an unlimited number that can be created. What matters is that they can implement a couple functions with the required properties. So I've said monads are abstract. What's the point then? Well, put simply, a language with the kinds of primitives Haskell has can actually put the abstraction into its libraries. This allows writing code that works at the level of the abstraction, rather than any specific implementation. The monad abstraction turns out to be rich enough to implement all kinds of conditionals, loops and recursion structures, function application patterns, etc. In fact, work with parser combinator libraries has shown that the monad abstraction is the simplest one that allows you to express any context-sensitive grammar. If you've ever studied automata theory, bells should be ringing about now. The monad abstraction is sufficiently rich to express Turing-complete operations over the kinds of types it applies to. And that's the real point. The monad interface allows you to specify those kinds of operations generically. Once they've been written, you can apply them to any type that provides the interface (correctly). The fact that there's an IO type that happens to provide the interface is an accident that's only relevant historically. The benefit is much larger than that. This kind of comes down to Rich Hickey's "simple vs easy" point. Monads are incredibly simple, but they're not easy for people who aren't used to looking for deep abstractions. One of the insights made in Haskell library design is that category theory contains several ideas that are incredibly simple and powerful as abstractions for software creation. Monad is hardly the only one - it's just the only one getting press.
gavinpc 14y ago
Notwithstanding the critics, I've read many explanations of Monads, and I found this one helpful, especially coming off of Eric Lippert's: http://stackoverflow.com/a/2704795/4525 http://stackoverflow.com/a/2704795/4525 I get it now, so thanks!
papsosouid 14y ago
>I disagree completely with his analysis on monads You say that, but your post doesn't actually show disagreement. He said to avoid analogies, not avoid real code. His list of steps in fact contains "use monads in real code".

by rtpg 14y ago

freyrs3 14y ago

The problem with bringing jQuery into the discussion is that it's not a monad. Don Stewart explains this more elegantly than I can [1] but the crux of the argument is that chaining together computations is not enough to be a monad, one needs to prove that the monad laws hold. [1] http://stackoverflow.com/questions/10496932/is-jquery-a-monad/10499668#10499668 http://stackoverflow.com/questions/10496932/is-jquery-a-mona...

sordina 14y ago
The majority of the 'proofs' I've seen that jQuery isn't a monad seem to either be probabalistic, or use the "Burden of Proof" argument to show that since nobody has proved that jQuery is a monad, we should assume that it isn't. I agree that jQuery probably isn't a monad, but it rubs me the wrong way that people aren't willing to say "It has yet to be determined if jQuery is a monad". Obviously it is trivial to show that it isn't a monad by the fact that javascript permits any action in pure code, but by the same token, unsafePerformIO proves that Haskell has no monads. I think it's fair to operate under a reasonable subset of jQuery functionality when asking the question.
- xyzzyz 14y ago
  The point is that the concept of monad is a very concrete thing. Monad is not "chaining operations". Monad is not "returning actions instead of values". Monad is not some vague concept. If JQuery is a monad, what are the monadic operations that make it a monad? What are its equivalents of return and bind (or any other equivalent definitions of a monad)? It's not a tricky question. Saying that JQuery is a monad without saying what its return and bind are is equivalent to saying that whistling is Turing complete without saying how you can compute stuff with whistling. The problem here is not whether whistling is Turing complete or not, the problem is what it would even mean for whistling to be Turing complete. This means that as of now, as long as you don't tell us what are the monadic operations of JQuery, it cannot be determined whether JQuery is a monad, because this question does not make sense yet.
  - jes5199 14y ago
    JQuery is an implementation of the List monad.
    - tome 14y ago
      JQuery is an enormous API, so it is implausible that it is an implementation of the list monad. Some aspect of it might be the list monad. If so, which?
      - jes5199 14y ago
        Most jQuery methods are functions that are mapped over a collection of elements. Many verbs return collections themselves, which are concatted together into the resulting collection. That's analogous to how List works. So $(element) implements return as a -> [a] And bind is mapcat, which is called by most of the jQuery methods. Yes, that's a subset of the API, but it's the subset that distinguishes jQuery from any other collection of helper functions.
        nbouscal 14y ago

tome 14y ago

Maybe is not the simplest monad, Identity is, and I think Maybe is an excellent example of a monad.

TheCoelacanth 14y ago
Identity is simpler, but it's not very interesting. It's hard for a beginner to see why you would ever use the Identity monad. Maybe is the simplest interesting monad, which makes it a good candidate for explaining monads to beginners.

sordina 14y ago

I'm not sure you actually disagree with his method of learning monads. He primarily advocates for avoiding the use of analogies, which you seem to agree with. He advocates using concrete monads in real code, which you also seem to agree with. The only contentious point might be learning typeclasses and how monads fit into the Typeclassopedia. If you want to be able to trace how your monad-using code is evaluated this is a necessity. Like it or not. Also, attacking monads from both the concrete and the abstract at the same time seems to be a good approach, with satori being achieved once the understandings meet. A dynamic-programming approach? You may possibly be disagreeing with the order in which he lists these components of learning in his 'Eightfold Path', but if the analogy to the Buddhist teachings is followed further, then the steps need not be taken in sequence. The slides certainly include many monad examples besides maybe at any rate. I think the slides are worth another look :)

kzrdude 14y ago

Your pipeline example looks more fit for simple function composition. f = filter (\x color x == BlueColor) . select (\x color x == RedColor)

jes5199 14y ago
That's true for this example, but when you do tree walking stuff in jQuery (like elements.children().children() ) then you have to think of it as a concatting map instead as just a regular map or filter

lmm 14y ago

Agree 100% on just showing the real code. Don't tell me what a monad is, tell me a problem I can solve with it. (I've made my own attempt at http://m50d.github.io/2013/01/16/generic-contexts.html http://m50d.github.io/2013/01/16/generic-contexts.html )

marshray 14y ago

I've read lots of monad tutorials. I get it, they're a way of encapsulating side-effects in a pure lazy language. But Haskell doesn't sink in unless I use on a regular basis. The time that I've felt like I was able to see a light at the end of the tunnel (i.e., that I might be able to be useful enough in Haskell that I could keep using it regularly) was when I simply memorized the expansions for the do, <-, return sugars.

chowells 14y ago
You've just proved that the monad tutorials you've read are useless. Monads are emphatically not "a way of encapsulating side-effects in a pure lazy language". Haskell's IO type is a way of encapsulating side effects in a pure lazy language. Haskell's IO type happens to form a monad. The fact that it forms a monad is completely irrelevant to what it actually does. Forming a monad is a very abstract consideration. It has to do with the data type supporting a couple operations with specific properties. It doesn't say a thing about what those operations mean, so long as the required properties hold. It's up to specific monads to insert semantics into those operations. And so yes, the IO type specifies that its monad operations mean "creating a trivial IO action that gives a specific value when executed" and "feed the result of executing an IO action into a function that returns another action." And that turns out to be a sufficient framework for composing IO actions together, once something else is providing them. But IO isn't the only monad. There are hundreds of others already defined, and an unlimited number that can be created. What matters is that they can implement a couple functions with the required properties. So I've said monads are abstract. What's the point then? Well, put simply, a language with the kinds of primitives Haskell has can actually put the abstraction into its libraries. This allows writing code that works at the level of the abstraction, rather than any specific implementation. The monad abstraction turns out to be rich enough to implement all kinds of conditionals, loops and recursion structures, function application patterns, etc. In fact, work with parser combinator libraries has shown that the monad abstraction is the simplest one that allows you to express any context-sensitive grammar. If you've ever studied automata theory, bells should be ringing about now. The monad abstraction is sufficiently rich to express Turing-complete operations over the kinds of types it applies to. And that's the real point. The monad interface allows you to specify those kinds of operations generically. Once they've been written, you can apply them to any type that provides the interface (correctly). The fact that there's an IO type that happens to provide the interface is an accident that's only relevant historically. The benefit is much larger than that. This kind of comes down to Rich Hickey's "simple vs easy" point. Monads are incredibly simple, but they're not easy for people who aren't used to looking for deep abstractions. One of the insights made in Haskell library design is that category theory contains several ideas that are incredibly simple and powerful as abstractions for software creation. Monad is hardly the only one - it's just the only one getting press.

gavinpc 14y ago

Notwithstanding the critics, I've read many explanations of Monads, and I found this one helpful, especially coming off of Eric Lippert's: http://stackoverflow.com/a/2704795/4525 http://stackoverflow.com/a/2704795/4525 I get it now, so thanks!

papsosouid 14y ago

>I disagree completely with his analysis on monads You say that, but your post doesn't actually show disagreement. He said to avoid analogies, not avoid real code. His list of steps in fact contains "use monads in real code".