On Fri, Mar 6, 2009 at 1:48 AM, Daryoush Mehrtash <span dir="ltr">&lt;<a href="mailto:dmehrtash@gmail.com">dmehrtash@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Question:  Do I need to worry about space leak if I am using the fix to instead of the &quot;let&quot;?</blockquote><div><br>If you need to worry about a space leak with fix, you need to worry about it with let.<br><br>The reason arrows can tie the loop tighter is more about the nature of recursion in streams; an arrow &quot;sees&quot; that prior values of a signal are not used, whereas value recursion is much less restricted.  If, for example, the arrow were a kleisli arrow over the list monad, this would not be possible.<br>
<br>With the definition fix f = let x = f x in x, you should not see any performance difference, other than the standard HOF penalty if there is not enough inlining... but that should not be asymptotic anyway.<br><br>Luke<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Thanks<br><br>Daryoush<br><div class="gmail_quote">2009/3/5 Luke Palmer <span dir="ltr">&lt;<a href="mailto:lrpalmer@gmail.com" target="_blank">lrpalmer@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"><div class="gmail_quote"><div>On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave <span dir="ltr">&lt;<a href="mailto:donn@avvanta.com" target="_blank">donn@avvanta.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;">
Quoth Jonathan Cast &lt;<a href="mailto:jonathanccast@fastmail.fm" target="_blank">jonathanccast@fastmail.fm</a>&gt;:<br>
<div><br>
&gt; You can certainly use let:<br>
&gt;<br>
&gt;   reader &lt;- forkIO $ let loop = do<br>
&gt;       (nr&#39;, line) &lt;- readChan chan&#39;<br>
&gt;       when (nr /= nr&#39;) $ hPutStrLn hdl line<br>
&gt;       loop<br>
&gt;     in loop<br>
&gt;<br>
&gt; But the version with fix is clearer (at least to people who have fix in<br>
&gt; their vocabulary) and arguably better style.<br>
<br>
</div>Would you mind presenting the better style argument?  To me, the<br>
above could not be clearer, so it seems like the version with fix<br>
could be only as clear, at best.</blockquote><div><br></div></div><div>I like using fix when it&#39;s simple rather than let, because it tells me the purpose of the binding.  eg., when I see</div><div><br></div><div>    let foo = ...</div>


<div><br></div><div>Where ... is fairly long, I&#39;m not sure what the purpose of foo is, or what its role is in the final computation.  It may not be used at all, or passed to some modifier function, or I don&#39;t know what.  Whereas with:</div>


<div><br></div><div>   fix $ \foo -&gt; ...</div><div><br></div><div>I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself.</div><div><br></div><div>


I know that it&#39;s a simple matter of scanning to the corresponding &quot;in&quot;, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying.  Now, that doesn&#39;t say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively.  I think fix is best with a single, named argument.</div>


<div><br></div><font color="#888888"><div>Luke</div></font></div>
<br></div></div><div class="im">_______________________________________________<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></div></blockquote></div><br><br>
</blockquote></div><br>