Proposal: Applicative => Monad: Call for consensus

[Jan-Willem Maessen]

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.

-Jan-Willem Maessen