Warp wrote:

>   Or I could simply make an overloaded version of the fold function which
> takes an iterator range.

Now what happens if you want to only process elements having some 
arbitrary property? (E.g., only the odd numbers.) Or what if the 
function you're trying to fold is non-associative, and you want to 
rearrange the list so the elements can be processed in a different order?

The idea behind Haskell's data processing function is that each function 
does *one* job, which makes it possible to combine them in any possible 
way. (This is not unlike the Unix idea of implementing complex 
functionallity by "piping" data between multiple simple utility 
programs, as seen in millions of shell scripts.) As soon as you start 
trying to rely on particular pre-combined functions, you lose that 
flexibility.

With lists in particular, the new stream-fusion library means that most 
if not all common combinations of list processing functions get 
automatically fused together by the compiler.

There used to be a function called "concatMap", which does the same 
thing as "concat . map", but more efficiently. It's actually still there 
for compatibility, but with stream fusion you don't actually need it any 
more [because "concat . map" gets optimised into the same thing].

If you really need killer performance on a critical region of your 
program... well actually, in that case you probably wouldn't be using 
lists anyway, but still... if you really need killer performance 
somewhere, you can manually fuse if the compiler somehow fails to do it 
for you. But otherwise, the code is much more maintainable if you don't.

Post a reply to this message