Add (Int, +) finger trees

[treeowl]

• Export a type for (Int,+) finger trees.
• Export more Data.Sequence internals.
• Offer a module of Data.Sequence internals intended
  for external use, that should obey the PVP.
• Remove Functor and Traversable instances for FingerTree and Node.
• Remove the Generic1 instance for FingerTree.

[treeowl]

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

[sjakobi]

@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.

[Lysxia]

Instead of this partial function, why not only export split and let users deal with partial patterns if they want?

[treeowl]

My only concern is whether that extra stuff will inline away. Certain functions are extremely sensitive to the performance of splitting tiny little sequences (e.g., 2–5 elements) where any little extra time/allocation can matter a lot. I'm not sure how hard it would be to rejigger Data.Sequence.Internal.splitTree to make sure that works out okay.

[treeowl]

@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.

[Lysxia]

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, +).

[treeowl]

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.

[sjakobi]

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?

[treeowl]

I don't even know if I'll be able to make that practical; it's just what got me here. I think another application is ropes: finger trees of byte arrays.

…

On Wed, Feb 3, 2021, 6:41 PM Simon Jakobi ***@***.***> wrote: 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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#766 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOOF7M4NJQRRIZPDL4CEETS5HNKTANCNFSM4XBTXOVA> .

[emilypi]

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?

[emilypi]

Do we have a debugging function that shows the split lying around? Would be useful to have.

[treeowl]

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?

[phadej]

I cannot comment on this (not sure why you asked me to review). finger trees are unfamiliar structures to me.

[phadej]

Would Data.Sequence.Unsafe be better name?