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

[Yves Parès]

> To move between functional and monadic code you have to completely
rewrite the code procedurally

I don't like the way people segregate "pure" from "monadic". Monadic code
*is* pure: it's written with completely pure Haskell and completely pure
combinators. As Alexander said, it's really important to say that 'do' is
just syntax over abstract combinators, and that it's *only for IO/ST* that
those combinators have something special.
This is why I do disagree with tutorials who begin by showing the 'do'
notation saying "do IO with that".
If the beginner reads that and then puts his learning aside (because he was
interested to get some input about Haskell but has no time to continue for
the moment), he walks away with the false impression that you have do
blocks to do imperative stuff, and for the rest you just use normal
functions.
People are there because they've heard about "the almighty *purely
functional* Haskell", I say let's give 'em what they came for:
    getLine >>= \x -> putStrLn ("Hello " ++ x ++ "!")
It's not complicated to understand the concept of an operator retrieving
the result of one operation and injecting it in the next.
Twist the syntax as you want if you think lambdas are not readable for
beginners, but still, if we begin by that, develop a little with a few more
examples and then say something like:
"But it would be very cumbersome to have to write everything like that. But
don't worry, with great purity does not come great integrism!
Haskell people have been intelligent and brought you a special syntax to
write it more legibly, *but it's actually exactly the same you're doing!*"
then the intuition that "monads are just like pure code" comes by itself.

This might be what leads people like Martin Odersky to false conclusions.

Amongst Haskellers I understand that we use this shortcut (pure VS monadic)
but as I said, towards non-Haskellers it's IMHO a bad idea to start
rightaway by making the difference between both.


Now, concerning Odersky's sentence specifically: "To move between
functional and monadic code
you have to completely rewrite the code procedurally":
I don't see how that differs from any other language: monads are just
patterns (*), if you start with one method and then switch to another then
you'll have to refactor.

I'd say monads are actually better in that respect, since they can abstract
a lot due to their inherent EDSL nature (provide just one type and its set
of operations, and then you can change everything under the hood).

(*) And because of their "pattern" nature, they have the same drawbacks
than patterns in OO: people may (and will) try to fit triangles in round
holes, i.e. to use a monad where another abtraction (or no abstraction at
all) would be better.

2012/6/24 Chris Dornan <chris at chrisdornan.com>

>     "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.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120624/2e4c10d2/attachment.htm>