On Wed, Dec 29, 2010 at 1:48 PM, Michael Lazarev <[email protected]>wrote:
> 2010/12/29 michael rice <[email protected]> > > 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 > 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/Control-Monad-Trans-RWS-Lazy.html 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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
