I like monadic reformulations when they remove repetitious patterns from code, such as reading/updating a single threaded state. I'm not yet seeing such a pattern in your case. As you mentioned:
The "shape" of the
state isn't constant throughout the process. At any given step, new
information may be added to the state, and old information may be thrown
away, if there is no further need for it.
So I'm still doubtful that a monadic approach is going to simplify your code. Would you give a real example of some code you'd like to make more manageable? If you have real examples of State, Reader, and/or Writer monads that strike you as similar to your example, please share that also.
Cheers, - Conal
On 12/26/06, Steve Schafer <steve@fenestra.com> wrote:
On Mon, 25 Dec 2006 09:52:47 -0800, you wrote:
>To my eye, your example code below looks less like an imperative
>program than like an intermediate form that a compiler would generate
>from an expression built up from nested function applications and a
>few "let"s.
That's very true, but the same could be said for many other examples
of the use of the State monad (and Reader and Writer as well). They
frequently don't do anything that couldn't be done purely
functionally.
Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe