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

[Chris Dornan]

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

> It's false.  do-notation is completely optional.  It merely makes it
> easier to extract multiple values from monadic actions, instead
> of the basic "one value per step" bind provides.   Using join
> and (>>=) is just as easy as do-notation, once you understand the idiom.

Odersky's point (and mine) was about moving between monadic and functional
code,
not eliminating a do notation (which is indeed a fairly trivial syntactic
device). To take
a fake and absurd example, there is a world of difference between

	add:: Double -> Double-> IO Double

and the stock addition operator. (Perhaps you need to be very careful about
exceptions.) If you structure your program so that certain kinds of
arithmetic has
to be done monadically then everything that uses these operations must be
written
quite differently from how it would be with simple arithmetic operations.

You can argue that well it's just in the types -- you pays your money and
takes you
choice. (Viz., if your function works with effects then it should be
expressed in its type.)
But then this becomes the price of doing everything in a strong functional
framework. To take one counter example, the Standard ML combines functional
programming and effects without forcing this reification on the programmer.

I much prefer the Haskell way. But when it get criticized by a
non-Haskellers I try
to understand the criticism in the context it was phrased.

> Haskell didn't invent monads.

Indeed, that  sloppy phrasing on my part. I meant Haskell invented 'monads'
as
they have come to be understood in the Haskell context (a general
programming
device for encapsulating effects-based code in a functional programming
context),
not the original algebraic construct or its mathematical applications.

Chris