Change reexports to specialize to type Array

[jvliwanag]

Wondering if the reexports should specialize to Array. That way, in my application code, Array.intercalate guarantees that I'm working with an Array.

This also helps with potential performance improvements by custom implementations later on that are specialized to Array.

[natefaubion]

Even though this is a breaking change, this has irritated me since forever and I would like this to be merged. I have never wanted to import generic foldable methods from a monomorphic library. It just makes no sense. It also means all these methods are necessarily and always worst case due to Foldable, so we rely on irritating hacks like findIndex followed by index.

[garyb]

I remember when we added these as re-exports in the first place I wasn't super enthusiastic about it, as I felt like it might obscure the fact that these operations are generic, and yeah, lead to some weird import/usage seeming contradictions.

I could understand a little bit if they were implemented more efficiently as per Nate's point, but I'm not a fan of monomorphizing them just for the sake of re-exporting. I'd rather remove the re-exports than do this, personally.

[natefaubion]

I think that there are probably quite a few usages in the wild that are appropriately monomorphic. I agree with you, but continuing to export them breaks less code.

[hdgarrood]

Are the Foldable versions of things really that bad in terms of performance here? Certainly the methods which are members of the Foldable class - that's foldl, foldr, foldMap - can be assumed to be equally as good as monomorphic functions because they essentially are. I wouldn't expect the difference between foldMap identity (which is how fold is defined) and a specialized version of fold to be that great. Note that any and all can't short-circuit because they are working with an arbitrary HeytingAlgebra so I wouldn't expect much difference with an Array-specialized version there. I feel like the only ones where I might expect more of a difference are the functions elem, notElem, find, and findMap, because they can't short-circuit once an element has been found, and scanl and scanr, because expressing them in terms of Traversable is a bit awkward.

[JordanMartinez]

To clarify, is the next action on this PR just fixing the conflicting files?

[hdgarrood]

I would prefer to replace the implementations of the functions I listed with versions which are implemented in terms of arrays specifically for performance - that is, elem, notElem, find, findMap, scanl, and scanr.

[natefaubion]

Note that any and all can't short-circuit because they are working with an arbitrary HeytingAlgebra so I wouldn't expect much difference with an Array-specialized version there.

I think that the monomorphic versions should be specialized to Boolean. You are correct, there is no performance advantage since they cannot short circuit (at least not without additional, dubious constraints), so having these monomorphic to Array but still generic over HeytingAlgebra gives us nothing. However, specializing it to Boolean is by far the most common case (I've never personally taken advantage of HeytingAlgebra generality) and I think beneficial. If you want that generality you can continue to use the Foldable implementations.

[kl0tl]

Do we still need this since #189 has been merged? For specialized short-circuiting any, all :: (a -> Boolean) -> Array a -> Boolean functions perhaps?

[JordanMartinez]

I'd say let's specialize all and any to Array and Boolean. As Nate pointed out, someone can use Foldable if they need the HeytingAlgebra constraint.

[kl0tl]

I opened #193.

[hdgarrood]

I think let’s close this for now then, since we’re going the route of providing optimised specialised versions rather than just specialising but keeping the same implementation. Thanks anyway for getting the ball rolling on this @jvliwanag!