[Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Andrew Coppin]

Yitzchak Gale wrote:
>
>
> And of course, you wouldn't want that:
>
> f xs = xs : map expensiveCalculation xs
>
> Please don't fuse those two loops into one.
>   

...doesn't type check. Did you mean (++)?

> In the case of "mean", the outer function in question
> is /, and that is a good candidate for fusion because
> it is strict in both arguments.
>
> I think Don is right. There is a lot of room for expanding
> the scope of fusion, but it needs to be done one function
> at a time until our strictness analysis gets better.
>   

Mmm, strictnes analysis. That sounds hard...

> In the general case, I like the way things work now. The original
> complaint about "unpredictability" is, in my opinion,
> a "bug in the documentation". This is yet another concept
> whose basics need to be made much more accessible to
> newbies.
>   

...which is really the point I was trying to get across, yes. :-)

Certainly there are experts [like Don] who seemingly have no trouble 
knocking out blindingly fast Haskell code. The problem is that only the 
halowed experts can do this; it's currently rather inaccessible to 
beginners and intermediates.

For example, back when I really *was* a beginner, I found several 
fleeting references to "laziness can be bad sometimes", but I couldn't 
find anywhere that explains *why*. The concept that laziness could be 
something you *don't* want seemed highly counter-intuitive. [After all, 
laziness is this wonderful thing that stops you doing extra work you 
don't need to!] Indeed, it wasn't until I wrote a Haskell interpretter 
that I discovered the [main] problem - huge unevaluated expressions 
being needlessly dragged around.

The fact that laziness is bad sometimes is a pretty basic piece of 
information for anybody remotely serious about performance programming 
to be made aware of. I think the information is out there, it's just not 
tefficially "findable" right now. I'm not 100% sure what the best way to 
improve this situation would be, but I think it involves somebody 
somewhere sitting down to write a single, coherant account from 
beginning to end explaining what the issues are, in language that people 
who aren't compiler designers can understand.