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.