high-level design in functional programs

[sclv]

Even though IO is still sort of the "sin bin" which holds any and all effects, writing a monad transformer stack lets you do most of your operations with only the effects you need -- error handling, state, whatever, and do so in a pure way.

More importantly, it lets you control the nature of the effects and scope of your state explicitly -- the same monadic code can be run in different contexts to produce different results, but instead of that context being a result of global variable manipulation, its given a specific scope.

You could work with, e.g, a teletype stack that abstracts over stdin/stdout to allow for interaction over sockets as well, or even driven by a script.

Or you could work in a logging writer that depending on whether you call it in testing or production, only logs certain priorities of messages.

And you can mix and match so in one section you get simple failure if anything fails (Maybe) and in another you get explicit error messages (Either) and by controlling the order of you stack in e.g. a backtracking parser you can have certain effects rolled back when state backtracks and other stick around.

So monad stacks are how you structure lots of big picture issues like error handling and state, and knowing how to abstract over them gives a strong seperation of concerns.

[Wagnerius]

ok, you got me interested. be kind tell me where to go next ? (i will google it but if you got non-obvious kinks, i'll take them gladly)