[mietek]

If anyone is being disingenuous here, it's you.

The first version [1] is simple and slow. The second version [2] is complex and fast.

The third, fast version [3] is identical to the first, simple version, with list processing functions imported from the `stream-fusion` package. This is the entire point of this article.

The only transformation shown is purely mechanical (prepending symbol names with the qualified import prefix `S.`), and even this is not required (as `Prelude` could have been imported `hiding` the appropriate symbol names instead).

[1]: http://www.mit.edu/~mtikekar/posts/src/collatz.hs

[2]: http://www.mit.edu/~mtikekar/posts/src/collatz1.hs

[3]: http://www.mit.edu/~mtikekar/posts/src/collatz2.hs

[vinkelhake]

Are there downsides to using the stream-fusion package? If not, why hasn't it been made the default so that the first naive version is fast?

[mietek]

As I understand, stream fusion is still subject of active research. A paper showing generalised stream fusion in Haskell was submitted to this year's ICFP.

There is also no benevolent dictator in charge of Haskell.

http://research.microsoft.com/en-us/um/people/simonpj/papers...

http://www.reddit.com/r/haskell/comments/1br0ls/haskell_beat...

[carterschonwald]

indeed. The generalized stream fusion work is about lifting pointwise operations to their SIMD vectorized analogue.

Likewise, stream fusion isn't always a win! Stream fusion and its siblings are great for pointwise operations, but aren't always a good idea for computations with heavy reuse, like nested convolutions or performant matrix multipy

[dons]

Complexity of concatMap operations. Nested things don't always fuse.

If you want to use fusion, the best place is the `vector` package.