[Haskell-cafe] Martin Odersky on "What's wrong with Monads"

[Chris Dornan]

    "What's wrong with Monads is that if you go into a Monad you have to
change your whole syntax
    from scratch. Every single line of your program changes if you get it in
or out of a Monad. They're
    not polymorphic so it's really the old days of Pascal. A monomorphic
type system that says 'well
    that's all I do' ... there's no way to abstract over things. " [0,
53:45]

     [0] - http://css.dzone.com/articles/you-can-write-large-programs

I think the context of the question is important here. Odersky is asked why
provide all this elegant machinery
for doing functional things while  avoiding the difficult/critical parts --
the parts that deal with the effects. 

Odersky seems to be making three claims.

  * To move between functional and monadic code you have to completely
rewrite the code procedurally -- its
    true and (IMHO) regrettable.

  * Monadic code is monomorphic: this appears to be seriously mistaken.
Monadic functions can be as polymorphic
    as any non-monadic functions. (I have never wished the lambda-bound
variables introduced by 'do' statements
    were somehow polymorphic.)

  * There is no way to abstract over monadic code: this also appears to be
mistaken as there are plenty
   of ways of abstracting while writing monadic code (using the very same
techniques you would use
   for non-monadic code).

Monads allow procedural code to be expressed procedurally and functional
code to be expressed functionally and
the type system ensures there are no mix ups. Expressing procedural code
functionally is as unnatural and error
prone as expressing functional code procedurally in my experience -- that
Haskell avoids compelling the programmer to
do either within its strongly-typed functional framework is (IMHO) its great
invention(*) and enduring strength.

Maybe someday someone will devise a way writing 'effects' code in a
strongly-typed functional framework
that doesn't force the programmer to commit each function to being either
procedural or functional -- or
better yet, do away with the need to write any effects code. Perhaps it has
been done already. (I don't doubt
folks have claimed to have done it.) But until there is a proven language
and tools that can do this, monads look
(to me, at least) like the best method for attacking 'effects' within a
strong functional framework.

Chris

(*) Monads were invented within the Haskell framework of course, after the
publication of the early reports and tools.