> > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe