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 <[EMAIL PROTECTED]> 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 [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
