Overhaul

[BurningWitness]

This is a full rewrite of the library, featuring, in order of implementation:

• Data.Patricia.Word.Strict: this is the same definitionally as IntMap, the only meaningful differences are that it uses Words as keys directly and that the API is way more frugal than in containers (also has a few cool functions, like range operations).

  This and every single other tree in the library shamelessly reuses the findings of the recent Optimize IntMap.Bin haskell/containers#995 PR for performance;

• Data.Patricia.Word.Lazy: slight variation on IntMap, spine-lazy. Almost all the functions are the same as for the strict version though;

• Data.Zebra.Word: IntSet, but instead of storing packed keys it stores space partitions.

  Technically this is a 2^64-wide bit array.

• Data.Radix1Tree.Word8.Strict: a spine-strict radix tree with non-empty byte sequences as keys.

  The internal implementation is similar to bytestring-trie, but without "non-trivial invariants". The tree does not have a concrete key type; instead, there are two types of keys: Feed for breaking an input key down into bytes (inlines for performance) and Build to reshape stored keys into new formats.

  Implements all the same functions as Data.Patricia.Word.Strict plus some more, with the exception of Range ones because those functions are gargantuan for radix trees, so they're both a pain in the butt to write and probably would not inline either way.

• Data.RadixTree.Word8.Strict: an extension to Radix1Tree that allows storing a value at an empty byte sequence.

  The entire interface is duplicated from the Radix1Tree, with the help of inlining.

• Data.RadixTree.Word8.Lazy and Data.RadixTree.Word8.Strict: spine-lazy radix trees. Same stuff as with Patricia trees: lots of code duplication, different asymptotics.

  These can store values at infinitely long keys, provided you never access them, how droll.

All of this is tested (for result-correctness, but no introspection testing), all of this is documented, none of this is benchmarked (I don't know what case to target, so I didn't bother).

Note that while this theoretically should support GHC 8.4 through 8.10, this is only reachable using a custom build due to the template-haskell >= 2.17 dependency, and as such that has not been tested.

[sergv]

This is great stuff, I'm ready to merge. I can as well add you to github/hackage maintainers so you can release too, if you wish.

Would you consider a couple of suggestions in the meantime?

[sergv]

For strict radix trees the signature is

splitL0 :: Openness -> Feed -> RadixTree a -> Split a a

Would it make sense to copy what containers do here and make strict version of splitL0 also return lazy tuple so that users can switch with no cost? Strict version will be a wrapper around working returning strict tuple and just repackage it into a lazy tuple.

[BurningWitness]

The introduction of Split and SplitLookup was a very late change from my side, the thing that irked me was that the strict splits went through the trouble of creating two completely strict values and then at the very end threw in two boxes in the form of a lazy 2-tuple. I as such prefer a strict tuple because I expect all results in the strict module to be strict.

copy what containers do ... so that users can switch with no cost

Lazy and Strict in this library do not mean the same thing as they do in containers. containers' definition is "everything in Lazy does not evaluate the value before putting into the tree, everything in Strict does", but their underlying implementation is spine-strict in both cases.

The difference between a split on a spine-lazy tree and a split on a spine-strict one is massive, so I don't see the need to have the two be directly interchangeable.

[sergv]

It seems that returning singleton strict tuples in cases like this could be avoided at no cost? Do these singleton tuples serve some purpose, in particular for the invert function?

[BurningWitness]

There's a nice explanation for what unboxed 1-tuples do on StackOverflow. For this particular case the the idea is that allocations for Black and White are shared, so there never is a need to evaluate the results to WHNF.

Had a little back-and-forth about it here, final STG seems to align with my expectations.

[sergv]

NB I'm not particularly worried about supporting GHCs before 9.2, if it works with them then great, if not then let them be.

[sergv]

It seems this is just a strict pair from the strict package. There's also strict Maybe in there so it would make senso switch.

This echoes another suggestion about unifying function types between lazy and strict versions of the API. Even if no unification is to take place, returning strict tuple from strict package seems better thar returning custom type isomorphic to it - the strict tuple has helpers to work with it whereas types like Split don't.

[BurningWitness]

Those helper functions will be pretty useless when it turns out your code looks like

let !(Radix.Split l r) = Radix.split _ _ a
in _

At the end of the day this is just the return type for a bunch of functions in this library and if I want to unpack or unbang something later on, I want to have that power. Also means we don't have to depend on three extra libraries.

---

There are broader points here of Haskell suffering from dependency hells and people shunning custom types, but this isn't a good time to rant about it.

[sergv]

I've added you to github collaborators for thi srepo. If you want to become Hackage maintainer so you can release then please provide your hackage username.

[BurningWitness]

The maintaner name is OleksiiDivak.

[sergv]

I've added you.

[jcranch]

Looks great! Are you willing to add it to Stackage? It is preferred that the package maintainer do so, though I am willing to do so if that would be a problem for you.

[BurningWitness]

@jcranch I personally don't care about Stackage, but I'm fine with anyone taking that responsibility, especially if they're already maintaining some other package there. I don't expect this package to break much (few dependencies, very wide bounds), so it shouldn't be a nuisance.