<br><br><div class="gmail_quote">On Mon, Jan 30, 2012 at 6:24 AM, Malcolm Wallace <span dir="ltr">&lt;<a href="mailto:malcolm.wallace@me.com">malcolm.wallace@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 29 Jan 2012, at 22:25, Ertugrul Söylemez wrote:<br>
&gt; A strict-by-default Haskell comes with the<br>
&gt; implication that you can throw away most of the libraries, including the<br>
&gt; base library.  So yes, a strict-by-default Haskell is very well<br>
&gt; possible, but the question is whether you actually want that.  I<br>
&gt; wouldn&#39;t, because a lot of my code relies on the standard semantics.<br>
<br>
</div>At work, we have a strict version of Haskell, and indeed we do not use the standard libraries, but have built up our own versions of the ones we use.  However, our compiler is smart enough to transform and optimise the source code *as if* it were non-strict: it is only at runtime that things are evaluated strictly.  This means that, in general, you can rely on the standard semantics to a surprisingly large extent.</blockquote>
<div><br></div><div>I wanted to emphasize Malcolm&#39;s point here.  Optimizing using the original Haskell semantics turned out to be pretty important back when I was working on Eager Haskell.  For example, a lot of Haskell functions are written in the following style:</div>
<div><br></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">f a b c</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">  | guard1 d = g h i</font></div><div>
<font class="Apple-style-span" face="&#39;courier new&#39;, monospace">  | guard2 e = h</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">  | guard3 f = i</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">  | otherwise = j</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">  where d = ...expensive...</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        e = ...expensive...</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        f = ...expensive...</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        g = ...expensive...</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        h = ...expensive...</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        i = ...expensive...</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">        j = ... expensive...</font></div><div><br></div><div>An an ordinary procedural language, where function calls in g, h, i, and j might have side effects, we can&#39;t sink bindings down to the point of use.  Even in the absence of side effects, we have to account for the fact that some of these computations are used in some -- but not all -- right-hand sides, and that often we need to do some inlining to discover that a value isn&#39;t going to be used.  It turns out Haskell code relies on this sort of thing all over the place, and simply coding around it leads to deeply-nested let bindings that walk off the right-hand edge of the screen.</div>
<div><br></div><div>It&#39;s not difficult to rewrite most of the prelude functions in this style, but it&#39;s no longer pretty, and it&#39;s recognizably not idiomatic Haskell.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

However, bulk operations do transform the entire data structure, not merely the fragments that are needed for the onward computation, so it can often be a net performance loss.  The standard lazy computational paradigm of generate-and-test is therefore hideously expensive, on occasion.<br>
</blockquote><div><br></div><div>This was a huge issue in Eager Haskell.  By far our worst performance was on stream-like programs that generated infinite lists of results, and then sliced away the useless tail.  With completely strict evaluation, this of course doesn&#39;t work at all, but it can be tricky to bound the required sizes of inputs even if you know how much of the output you want (imagine a call to takeWhile or filter on an infinite list).</div>
<div><br></div><div>-Jan-Willem Maessen</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
    Malcolm<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>