On Thu, Dec 10, 2009 at 4:42 PM, Stephen Tetley <span dir="ltr">&lt;<a href="mailto:stephen.tetley@gmail.com">stephen.tetley@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;">
C&#39;mon Andrew - how about some facts, references?<br>
<br>
2009/12/10 Andrew Coppin &lt;<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>&gt;:<br>
<div class="im"><br>
<br>
&gt; 1. Code optimisation becomes radically easier. The compiler can make very<br>
&gt; drastic alterations to your program, and not chance its meaning. (For that<br>
&gt; matter, the programmer can more easily chop the code around too...)<br>
<br>
</div>Which code optimizations?<br></blockquote><div><br>Anything permitted by free theorems for one. That gives you a whole lot of code motion possibilities. Purity also gives the compiler freedom to increase sharing. It lets GHC rely on &#39;almost correct&#39; ways to evaluate thunks on multiple cores with blackholing that has a vanishingly small but still existent race condition, which is FAR faster than the version they would have to use if they were more concerned about accidentally duplicating effects. <br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt;From a different point of view, whole program compilation gives plenty<br>
of opportunity for re-ordering transformations / optimization - Stalin<br>
(now Stalinvlad) and MLton often generated the fastest code for their<br>
respective (strict, impure) languages Scheme and Standard ML.<br>
<br>
Feel free to check the last page of the report here before replying<br>
with the Shootout - (GHC still does pretty well though easily beating<br>
Gambit and Bigloo):<br>
<a href="http://docs.lib.purdue.edu/ecetr/367/" target="_blank">http://docs.lib.purdue.edu/ecetr/367/</a><br>
<div class="im"><br>
&gt; 2. Purity leads more or less directly to laziness, which has several<br>
&gt; benefits:<br>
<br>
</div>Other way round, no?<br></blockquote><div><br>Laziness pushes you in the direction of purity, if only because it provides you with the freedom you need to recover usable efficiency, but I would argue that the converse is also true to some extent.<br>
<br>When you are designing a pure language, you can&#39;t do as much in a strict setting as you can in a lazy setting. Laziness allows you to tie the knot without mutation -- or rather using only the mutation intrinsic to thunk-evaluation in call-by-need. <br>
<br>A pure strict language is also often faced with some kind of fun/val distinction, leading to ml like syntactic warts, and eta-reduction isn&#39;t always sound, so EDSLs wind up carrying extra ()&#39;s or need pointful plumbing ala f#&#39;s |&gt;. <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;"><div class="im">
&gt; 2a. Unecessary work can potentially be avoided. (E.g., instead of a function<br>
&gt; for getting the first solution to an equation and a seperate function to<br>
&gt; generate *all* the solutions, you can just write the latter and laziness<br>
&gt; gives you the former by magic.)<br>
&gt;<br>
<br>
</div>Didn&#39;t someone quote Heinrich Apfelmus in this list in the last week or so:<br>
<br>
<a href="http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html" target="_blank">http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html</a><br>
<br>
&quot;Well, it&#39;s highly unlikely that algorithms get faster by introducing<br>
laziness. I mean, lazy evaluation means to evaluate only those things<br>
that are really needed and any good algorithm will be formulated in a<br>
way such that the unnecessary things have already been stripped off.&quot;<br></blockquote><div><br>Continuing that quotation seems to say quite the opposite.<br><br>&gt; I mean, lazy evaluation
means to evaluate only those things that are really needed and any good
algorithm will be formulated in a way such that the unnecessary things
have already been stripped off. But laziness allows to simplify and
compose algorithms. <br><br>Not only that but the surrounding example is the classic &#39;take 5 . qsort&#39;, which DOES change its asymptotics in the face of laziness. When you are writing the algorithm from scratch, I agree that it is the case that you probably derive nothing from laziness. The nice thing about laziness is that it permits you to avoid this tedium and makes it easier to grab a widget from the standard library and just have it suit your purposes.<br>
<br>Another non-intuitive asymptotic changing difference is that laziness provides a side-effect free way to describe memoization and dynamic programming over certain domains.<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;">

<a href="http://apfelmus.nfshost.com/quicksearch.html" target="_blank">http://apfelmus.nfshost.com/quicksearch.html</a></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
&gt; 2b. You can define brand new flow control constructs *inside* the language<br>
&gt; itself. (E.g., in Java, a &quot;for&quot; loop is a built-in language construct. In<br>
&gt; Haskell, &quot;for&quot; is a function in Control.Monad. Just a plain ordinary<br>
&gt; function that anybody could write.)<br>
<br>
</div>Psst, heard about Scheme &amp; call/cc?<br></blockquote><div><br>To be fair, most scheme control structures are implemented using macros, and call-by-macro-expansion is a form of call-by-name:<br><br><a href="http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_macro_expansion">http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_macro_expansion</a><br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
&gt; 2c. The algorithms for generating data, selecting data and processing data<br>
&gt; can be seperated. (Normally you&#39;d have to hard-wire the stopping condition<br>
&gt; into the function that generates the data, but with lazy &quot;infinite&quot; data<br>
&gt; structures, you can seperate it out.)<br>
<br>
</div>Granted. But some people have gone quite some way in the strict world, e.g.:<br>
<br>
<a href="http://users.info.unicaen.fr/%7Ekarczma/arpap/FDPE05/f20-karczmarczuk.pdf" target="_blank">http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf</a><br><div class="im"></div></blockquote><div><br>
Given. But then people have written some amazing things in brainfuck too. That doesn&#39;t mean that I want to subject myself to working in such a sufficient computing environment :)<br><br><br><br><br></div>-Edward Kmett<br>
</div>