<div dir="ltr">2008/8/18 Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span><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;">

<div><br>
On 16 Aug 2008, at 8:35 am, Kevin Scaldeferri wrote:<br>
<br>
</div>There is a tradeoff.<br>
When your compiler does good stuff like constant propagation,<br>
inlining, loop unrolling, loop fusion, &c, it gets hard to make<br>
'the line number' mean anything.  For example, suppose we had<br>
<br>
        Ns = [sum(L) || L <- Ls],<br>
        Ds = [length(L) || L <- Ls],<br>
        Aves = [N/D || {N,D} <- lists:zip(Ns, Ds)]<br>
<br>
This is the kind of thing the GHC compiler eats for lunch;<br>
assuming Ns and Ds are not used anywhere else it turns into<br>
the equivalent of<br>
<br>
        Aves = [sum(L)/length(L) || L <- Ls]<br>
<br>
Which line does this correspond to?  ALL of them.<br>
(Actually, I believe GHC will take this a stage further, and inline<br>
and fuse the sum and length loops as well.  In which case we have<br>
code within a single "line" coming from several files.)<br>
<br>
The Erlang compiler isn't that smart.  (Yet.  A man can dream.)</blockquote><div><br>One problem Erlang would have doing this type of optimisation, which would be wonderful to have, is the handling of side effects and errors. That type of aggressive inlining and fusing would change the order in which side effects occur which means that the code would not be equivalent. Similar for errors. Haskell, being side-effect free, does not have this problem.<br>
<br>Robert<br><br></div></div></div>