[Haskell-cafe] Two-iteration optimisation (was:
andrewcoppin at btinternet.com
Thu May 15 16:45:32 EDT 2008
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
...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.
More information about the Haskell-Cafe