Is vector susceptible to the same fusion problems as text?

[konsumlamm]

Is fusion in vector susceptible to the issues described in haskell/text#348? If so, should we think about disabling implicit fusion for vector as well?

The PR says that fusion is more useful for libraries like vector for long chains of transformations. However, I, at least, wouldn't write long chains of transformations with vectors either, because I don't want to rely on fusion rules, that may or may not fire (and may even make performance worse!), for performance. I'd rather explicitly use streaming or use mutable vectors for the intermediate transformations.

If I understand correctly, disabling implicit fusion would also improve compile times. Although the way vector seems to be designed, it might be hard (to the point of not being feasible) to decouple it from the fusion framework.

[lehins]

should we think about disabling implicit fusion for vector as well

My opinion is a big NO!

issues described in haskell/text#348?

This issue provides tail as an example. In vector slicing implemented with with O(1) operations that do not utilize fusion. So that example isn't applicable to vector.

I, at least, wouldn't write long chains of transformations with vectors

Maybe you don't, but many people depend on it, often even without realizing it. I've personally written code that relies on the fact that operations fuse together.

Removing fusion is totally out of the question in vector at this point, IMHO, because this would affect an enormous amount of code out in the wild, most likely in a negative way. I wish vector had a more reliable fusion mechanism, like the one in massiv for example, where fusion is guaranteed because it is driven by the type system, rather than a whole collection of rewrite rules.

For those who need flat vectors without any fusion they can use primitive directly. Sure they will loose constant slicing and safe operations, but at least the performance will be reliable.

In any case, If there is indeed the need for vectors without fusion, which sounds sensible to me, I would rather recommend writing another library that provides the same drop-in interface as vector, but without fusion. In fact all of the type classes defined in vector could be reused, but the types would have to be redefined because instances would be different

Again if there is indeed need for this (a discussion on mailing list or CLC proposal?) and someone is willing to do the work we could solve this by creating:

• vector-core that contains the Vector and MVector type classes
• vector-nostream that defines all types with the same names with new instances and the same api as vector, but no fusion. (note that Unbox class with all of its instances will have to be redefined too)
• vector stays mostly unchanged, except depends on vector-core

This is the most reasonable solution I can think of because:

• It doesn't break existing code
• Provides extra functionality that wasn't available before (meaning guaranteed performance due to lack of fusion)
• Cool thing about this approach is that for types from vector-nostream it would be possible to regain streaming on demand by using Data.Vector.Generic interface.

[konsumlamm]

Thanks for your long explanation. Having a vector-core package might be a good idea, but it should be its own issue. I also found contiguous which aims to offer a unified interface for primitive arrays (it's currently unsafe, but byteverse/contiguous#49 discusses a safe interface).