<br><br><div class="gmail_quote">On Thu, Jul 15, 2010 at 10:34 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;">
Thanks David for the detailed explanation.<br><br>A couple of quick clarifications - <br><br>1. Even the &quot;invisible&quot; state that gets modified during the monadic evaluation is referred to as side effect right?<br>
</blockquote><div><br></div><div>If the state is free of types that allow for side effects then the state threaded through a state monad is also free from side effects.  If the state contains some IO type, which allows for side effects, for example, that state is affected by outside influences and is no longer pure.</div>
<div><br></div><div>Non-monadic example:</div><div><br></div><div>foo :: Int</div><div>foo = let state1  = 1</div><div>             state2 = state1 + 3</div><div>             state3 = state2 + state1</div><div>         in state3 + 9</div>
<div><br></div><div>Each of those states are really just labels on a stage of computation that&#39;s been done so far up to a final expression which is the result of the function foo being called.   In the end, this function is just a fancy way of saying 14 is an Int and foo could have been replaced with a let foo=14 in some other expression.</div>
<div><br></div><div>This is a pure function with what looks like states updating a value to produce a new state.  That&#39;s more akin to what happen in the state monad.  At no time is a previous state truly &quot;overwritten&quot; as that could be considered a side effect. </div>
<div><br></div><div>Here&#39;s a state monad like example of the same:</div><div><br></div><div>foo :: Int</div><div>foo = (flip execState) 1 $ do { </div><div><span class="Apple-tab-span" style="white-space:pre">                </span>          state1 &lt;- get;</div>
<div><span class="Apple-tab-span" style="white-space:pre">                </span>          modify (+3);</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>          state2 &lt;- get;</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>          put (state2 + state1);</div>
<div><span class="Apple-tab-span" style="white-space:pre">                </span>          modify (+9)</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>        }</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>2. I am a little unclear about &quot;in-place&quot; - does pure Haskell let one do such a thing-  or does it need to be done using FFI only?<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div>
<div>Pure haskell does not allow for in place update of values because that would violate the definition of purity.  That said, there are ways to update values in place with Haskell, ideally with Monads to control and sequence those side effects.</div>
<div><br></div><div>Example here:</div><div><a href="http://www.haskell.org/haskellwiki/Monad/ST">http://www.haskell.org/haskellwiki/Monad/ST</a></div><div><br></div><div>The ST monad allows one to describe a thread of computation which can update some mutable state and then exchange it with the &quot;pure world&quot; of normal Haskell computation.</div>
<div> </div><div>Dave</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Jul 15, 2010 at 10:48 PM, David Leimbach <span dir="ltr">&lt;<a href="mailto:leimy2k@gmail.com" target="_blank">leimy2k@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><br><br><div class="gmail_quote"><div><div></div><div>On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap <span dir="ltr">&lt;<a href="mailto:ckkashyap@gmail.com" target="_blank">ckkashyap@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;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></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="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;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" target="_blank">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>
</blockquote></div><br><br clear="all"><br></div></div>-- <br>Regards,<br><font color="#888888">Kashyap<br>
</font></blockquote></div><br>