<br><br><div class="gmail_quote">On Wed, Dec 29, 2010 at 1:48 PM, Michael Lazarev <span dir="ltr"><<a href="mailto:lazarev.michael@gmail.com">lazarev.michael@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2010/12/29 michael rice <<a href="mailto:nowgate@yahoo.com">nowgate@yahoo.com</a>><br>
<div class="im">> 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.<br>
<br>
</div>That is right. You need transformers if you want to have one value as<br>
settings to read, other value as a state, and so on, and they must be<br>
simultaneously accessible in some function. Or, for example, if you<br>
want to build a sequence of IO actions by functions that share the<br>
same environment.<br>
<br>
After you said that you had an "Aha!" moment, I remembered how I had<br>
something alike not very long ago. That was surprising event when I<br>
ended up with some transformer stack written myself although just<br>
several minutes ago I would consider this to be some dark wizardry.<br>
<br>
When I was dealing with monads for the first time, I tried reading<br>
source code and explanations. Soon I found that pure unapplied theory<br>
was making such a dismal, depressing feeling on me that I was not able<br>
to continue.<br>
<br>
But some time after I was writing an application in Haskell. It was<br>
real, and contrary to my previous theoretical studies the process was<br>
much fun. I had good FP background at that time, and had no problem<br>
writing everything in functional style. Since everything that can be<br>
done with monads can also be done without them, I didn't use any monad<br>
except IO (in main function :) ). Not that I especially avoided them,<br>
I just didn't think about them.<br>
<br>
And then I noticed that I constantly pass one same parameter to a lot<br>
of functions. And then -- since I remembered the boring theory -- bam!<br>
-- I introduced Reader into the code. And it worked. Which tempted me<br>
to interweave Reader and Writer, and so on, and twenty minutes later I<br>
had monstrosity that I only saw before in others' code: ReaderT<br>
WriterT State .... and so on :)<br>
<br></blockquote><div><br></div><div>Reader Writer State is commonly needed in big applications so transformers provides one for us:</div><div><br></div><div><a href="http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS-Lazy.html">http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS-Lazy.html</a></div>
<div><br></div><div>Pretty cool stuff if you ask me. I often wondered about the correct stacking order of Monad transformers, or how often it mattered.</div><div><br></div><div>Dave</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, good luck with your application!<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>