2011/1/9 Conal Elliott
... [fair points deleted.] I relate to Gábor's points that
* The familiarity advantage of (>>=) is a historical accident. I like to see the language improve over time, rather than accumulate accidents. * I prefer functions & methods with simpler interfaces over more complex interfaces. I'm happy to compose these simpler operations to get more complex operations, e.g. join+fmap vs (>>=).
I find this pretty funny, actually, because the early papers on monads in a programming context still used the categorical formulation in terms of join, and were pretty opaque reading as a consequence! When things are re-stated in terms of >>=, the parallels with interchange of let-bindings suddenly becomes obvious and it becomes possible to start to explain this stuff to programmers or computer architects (rather than mathematicians). This is a bias I developed from actually trying to teach this stuff in 1-2 lectures to advanced undergrads and grad students. Which of course says nothing about which form is easier to *write*, but I'm inclined to believe that it's easiest to read and write the form whose use you understand best (ie brevity is not the sole criterion here by any means; understandability has to be paramount). My bias is to assume my reader is, like me, a programmer first and a mathematician second. For example, I find it relatively easy to understand >>= in the continuation monad, but have to spend a long time puzzling my way through join. For simple stuff like [] and Maybe, of course, the code complexity argument is moot, and join is pretty natural unless you spend your time re-formulating list comprehensions for fun. -Jan-Willem Maessen