Proposal: Applicative => Monad: Call for consensus
jmaessen at alum.mit.edu
Sun Jan 16 04:43:32 CET 2011
2011/1/9 Conal Elliott <conal at conal.net>:
> ... [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.
More information about the Libraries