@emilypi and @Lysxia, I'd especially appreciate if one of you would check my documentation for the splitting functions in Data.FingerTree.IntPlus.

@treeowl Could you say something about the motivation for this PR? Ideally create an issue, so we can discuss the "problem" separately from this implementation.

@treeowl Could you say something about the motivation for this PR? Ideally create an issue, so we can discuss the "problem" separately from this implementation.

What really triggered it for me was wanting to play with incremental quicksort for sequences. Doing that (reasonably) efficiently requires use of FingerTree (Seq a) (which is a lot like Seq (Seq a), but with different annotations and therefore different splitting behavior). And the simplest (not simple) approach requires something like the splitMap function, which we already use to implement zipWith and chunksOf.

In principle, it would be nice to expand from (Int, +), to any Int-based monoid. But I'm scared of the efficiency considerations of doing that, and I don't know of any reasonably nice interface that doesn't lean on the extremely non-portable Coercible machinery. That is, one could imagine

data FingerTree s a
class Sized s a | a -> s where size :: a -> s
(<|) :: (Coercible s Int, Monoid s, Sized s a) => a -> FingerTree s a -> FingerTree s a

but then we're relying on an additional specialization along with all that non-portable stuff. Youch. So I figured I'd start with something conservative.

I was about to mention https://hackage.haskell.org/package/fingertree but if the goal is to implement "incremental quicksort" for Seq it does seem necessary to do this in containers and sufficient to keep it specialized to (Int, +).

I was about to mention https://hackage.haskell.org/package/fingertree but if the goal is to implement "incremental quicksort" for Seq it does seem necessary to do this in containers and sufficient to keep it specialized to (Int, +).

Well... not strictly necessary, I don't think, but the Ints are unpacked here (but not there). That seems especially important for the very short sequences. Also, the fingertree package has fallen behind in some optimizations.

So, do you intend to offer this incremental quicksort from a different package? Otherwise I don't understand why we need to enhance the public / stable API for this.

Or are you possibly talking about different sequence types than Seq here?

This looks good on first pass!

Unless i'm missing something (i'm not super familiar with this library's internals), there are a few improvements we can make to ergnomics here. For example, I cannot fromList [1..10]. I must fromList $ Elem <$> [1..10], since Sized has only two instances. The ability to debug splits would also be welcome.

Thoughts?

That fromList "limitation" is kind of essential to this structure. But we can add more Sized instances. I believe this PR adds one for Seq, we can get one for Array (and UArray?), and I guess inefficient ones for lists and non-empty lists too. Then there are potential derived instances for various base newtypes. Did you check my logic/arithmetic for splitting? And do you have a better name for split?