<br><br><div class="gmail_quote">On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap <span dir="ltr">&lt;<a href="mailto:ckkashyap@gmail.com">ckkashyap@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>I looked at State Monad yesterday and this question popped into my mind. From what I gather State Monad essentially allows the use of Haskell&#39;s do notation to &quot;invisibly&quot; pass around a state. So, does the use of Monadic style fetch us more than syntactic convenience?<br clear="all">

Again, if I understand correctly, in Mutable Arrays also, is anything getting modified in place really? If not, what is the real reason for better efficiency?<br></blockquote><div><br></div><div>Syntactic convenience is important, and allows for the separation of logic into different modular pieces. The do notation is totally independent of the Monad in question&#39;s behavior. You can even roll your own Monad if you wish, and the do notation will work. Consider if you had a big data structure that you had to pass around all the different versions of in a series of functions. Then consider what happens when you decide that some of your data has to change later as your program evolves over time. Having to change the state that&#39;s being threaded around is quite a pain when it can be done transparently at the Monad definition level.</div>
<div><br></div><div>Monads let you define the stuff that&#39;s going on between statements of do syntax. Some say it&#39;s the equivalent of overriding a fictional &quot;;&quot; operator for sequencing imperative looking code statements. There&#39;s much power to be had here, and because of this analogy, it&#39;s easy to see why Monads are a good place to implement an embedded specific sublanguage in Haskell.</div>
<div><br></div><div>I also think that because you&#39;re writing the glue between statements when you implement a Monad that it could be why some people (myself included) sometimes have a difficult time thinking of how to implement a particular Monad.</div>
<div><br></div><div>Monads also allow you to package up pure data values with some computational activities that might have side effects and logically separate them. This allows one to unwrap a value from a monadic environment and pass it to pure functions for computation, then re-inject it back into the monadic environment.</div>
<div><br></div><div>Monads are a good place to store side-effectful code, because they allow you to get away with causing a side effect and using some of those unwrapped monadic values in your pure code. They are an interface between two worlds in this respect. Monads are a good place, therefore, to implement code that does do in-place updates of values because they help the functional programmer deal with the issues of sequencing as well as interfacing side-effect-having and pure code and how to express dependencies between these two worlds.</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">-- <br>Regards,<br><font color="#888888">Kashyap<br>
</font><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>
<br></blockquote></div><br>