10

What are the origins of the syntax ">>=" and ">>" in Haskell Monads? I'm not looking for a explanation of how Monads work but instead why the language designers chose that syntax. To me, ">>=" and ">>" seems kind of arbitrary and never made intuitive sense. Does anyone have a intuitive explanation? Is it syntax that comes from category theory?

keyworks
  • 345
  • 5
  • 10

1 Answers1

17

m >>= k suggests "feed the result of computation m to the function k"; m >> n suggests "run the m computation and then the n computation".

duplode
  • 33,731
  • 7
  • 79
  • 150
  • 1
    If I recall correctly, the `>>=` sign is explicitly part of the Haskell logo. Where the lambda is the second `>`. :D – Willem Van Onsem Apr 15 '14 at 20:45
  • 8
    @CommuSoft Yes, but the logo is relatively new. It was chosen in 2009. Haskell 1.0 was released in 1990, and didn't even have monads. They were introduced in Haskell 1.3 from 1996. So the logo is certainly not a reason for the choice of name. It is rather the other way round. Monads are seen as an important feature of Haskell, and the choice of syntax for bind is rather unique to Haskell, therefore it's reflected now in its logo. – kosmikus Apr 15 '14 at 21:26
  • This answer corresponds to my current mental model, but the `>>` part does not make any sense to me. `>>=` or `>=` suggests some kind of piping, so `|=` would be more appropriate as an operator to denote dropping the left part of the context. I'd really like to be handed some link (to a mailing list?) where they discuss what drove them to use these operators, hoping to establish a sound mental model of those operators. – Sebastian Graf May 16 '14 at 16:50
  • @Sebastian If it was just about piping function composition would be enough. `g . f $ x` sends `x` down a pipeline made by `f` and `g`, in that order. With monads (and, in partly different ways, with functors and applicatives too) what comes into play is a distinction between values and a *context* in which they can be in. `>>` discards values, but not their context. An illustration: while `Just 1 >> Just 2` shows the `1` being discarded, `Nothing >> Just 2` shows that the context (in this case the choice between `Just` and `Nothing) of the first argument affecting the final result. – duplode May 16 '14 at 17:48
  • @Sebastian As for your broader question, grokking `>>=` (of which `>>` is just a special case) amounts to grokking monads, and the best way to do that is to play with them until it clicks. That being so, rather than leading you to any supposedly ultimate explanation of monads, I will just point to a more specific question about `>>=` with several good answers that you may find helpful: http://stackoverflow.com/q/23051800/2751851 – duplode May 16 '14 at 17:52
  • @duplode I think I can handle monads pretty well and already have some intuition. But the operator glyphs are just cryptic to me. I'd like to know the reasoning behind choosing them. I actually understand code using those, but for a well conceived language like Haskell I hoped there was some association (even category theoretic) between syntax and semantics. – Sebastian Graf May 16 '14 at 18:11
  • 3
    @Sebastian We have to remember that what originally brought monads to Haskell was I/O, and in that case `>>` meaning and-then, as in imperative sequencing, matches intuition. The idea is more precise and general than that, thanks to the bird's-eye view that takes monads as functional implementations of various imperative semantics. Suggested reading: [Wadler's papers on monads](http://homepages.inf.ed.ac.uk/wadler/topics/monads.html); [A History of Haskell: being lazy with class](http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/) for historical background. – duplode May 16 '14 at 18:39