
On Wed, Dec 29, 2010 at 1:48 PM, Michael Lazarev
I had an "Aha!" moment and it all makes sense now. Just as the State monad can hold a generator (which can change) and pass it down a calculation chain, a Reader monad can hold an environment (which doesn't change) and
2010/12/29 michael rice
pass it down a calculation chain. I was wondering how I could include a (global) house betting limit in that craps application I've been playing with (without passing it as a parameter) and it sounds like the Reader monad would be an ideal candidate. Correct? It also sounds like a job for monad transforms. That is right. You need transformers if you want to have one value as settings to read, other value as a state, and so on, and they must be simultaneously accessible in some function. Or, for example, if you want to build a sequence of IO actions by functions that share the same environment.
After you said that you had an "Aha!" moment, I remembered how I had something alike not very long ago. That was surprising event when I ended up with some transformer stack written myself although just several minutes ago I would consider this to be some dark wizardry.
When I was dealing with monads for the first time, I tried reading source code and explanations. Soon I found that pure unapplied theory was making such a dismal, depressing feeling on me that I was not able to continue.
But some time after I was writing an application in Haskell. It was real, and contrary to my previous theoretical studies the process was much fun. I had good FP background at that time, and had no problem writing everything in functional style. Since everything that can be done with monads can also be done without them, I didn't use any monad except IO (in main function :) ). Not that I especially avoided them, I just didn't think about them.
And then I noticed that I constantly pass one same parameter to a lot of functions. And then -- since I remembered the boring theory -- bam! -- I introduced Reader into the code. And it worked. Which tempted me to interweave Reader and Writer, and so on, and twenty minutes later I had monstrosity that I only saw before in others' code: ReaderT WriterT State .... and so on :)
Reader Writer State is commonly needed in big applications so transformers provides one for us: http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Co... Pretty cool stuff if you ask me. I often wondered about the correct stacking order of Monad transformers, or how often it mattered. Dave
So, good luck with your application!
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe