[Haskell-cafe] Martin Odersky on "What's wrong with Monads"
chris at chrisdornan.com
Sun Jun 24 11:48:32 CEST 2012
> > 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
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
to be done monadically then everything that uses these operations must be
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
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'
they have come to be understood in the Haskell context (a general
device for encapsulating effects-based code in a functional programming
not the original algebraic construct or its mathematical applications.
More information about the Haskell-Cafe