On Aug 30, 2005, at 12:13 PM, Bayley, Alistair wrote:
From: Duncan Coutts [mailto:duncan.coutts@worcester.oxford.ac.uk]
This is often a misconception, that just because you find you need to 'do' something in the middle of your algorithm, that you need to convert it wholly to monadic style.
Yes. However, Wadler makes a convincing (at least to me) case that the monadic style is easier to extend. The code changes for the monadic style appear to be more localised.
Something else I noticed about my non-monadic code was the way I was threading state through functions. I was tempted to introduce a State monad to make this easier to manage, but then I decided to try mutable arrays instead, so that experiment was not attempted. So it might well have been better in monadic style anyway, even with immutable arrays.
I'm conscious that for most (?) monads, monadic code can be invoked from non-monadic code. I'm only aware of the IO monad as a one-way trap. So changing code from pure to monadic doesn't necessarily involve program-wide changes, unless the monad you're introducing happens to be IO. In my array example, I introduced STArrays, but the main interface remained pure (non-monadic), which was my goal.
I was also wondering what the disadvantages of monadic style are? Are there compiler optimisations which are not possible with monadic code?
Both the advantage and the disadvantage is that you break lazy evaluation. 90% of the time lazyness is your friend and monadifying your code can break some nice features, but there is an occasional 10% of the time when it's useful to break lazyness. On a side note, whenever I find myself tempted to pass state around, I consider whether using CPS is better... It provides some method of ordering code, but doesn't break lazyness. Just 2¢ from a relative newbie. Bob