Improve compare for IntSet and IntMap

[meooow25]

Compare the trees directly instead of converting to lists.
The implementation follows broadly the same approach as the previous attempt in commit 7aff529.

Closes #470, closes #787.

Benchmarks with GHC 9.10:

Map

Name       Time - - - - - - - -    Allocated - - - - -
                A       B     %         A      B     %
compare    167 μs   32 μs  -80%    767 KB    0 B   -100%

Set

Name              Time - - - - - - - -    Allocated - - - - -
                       A       B     %         A      B     %
compare:dense      55 μs  412 ns  -99%    640 KB   12 B   -99%
compare:sparse     87 μs   26 μs  -70%    893 KB    0 B   -100%

[treeowl]

I'm having trouble understanding why we need a fancy result type for the go function. What's going on here?

[meooow25]

For a lexicographical comparison of the elements it's not enough to use Ordering. Suppose we have

t1 = [0]   [2]
t2 = [0,1] [2]

then comparing the left branches (compare [0] [0,1]) would return LT, but the overall result should be GT.
Detecting whether one set is a prefix of the other lets us handle this correctly.

[treeowl]

For a lexicographical comparison of the elements it's not enough to use Ordering. Suppose we have
[...]
Oh right ... That makes sense.

[treeowl]

The constructor names of the result in this context seem rather opaque to me. I assume this is reusing a type from somewhere else? Maybe we should make a new one.

[meooow25]

The type is introduced in this PR. The constructor names are from the previous attempt (7aff529), I don't mind changing them if you have suggestions.

[meooow25]

What names would you prefer @treeowl?

[meooow25]

Okay, this is good to go.
@treeowl would you still like me to change the names?

[treeowl]

I think that's much better, but a bit more documentation is in order.

[treeowl]

Please add a Haddock string.

[meooow25]

Why? These functions are not exposed.

[treeowl]

My general philosophy is that every top level function and every non-trivial function should be fully documented. For leftmostTipSure, I recognize that the name really gives it away, but I'm stubborn. orderTips must surely have a documentable purpose, with some expectations about what its arguments will mean and some description of what its result means.

[meooow25]

Sorry, I disagree. There is nothing to be gained by adding noise to internal functions with self-explanatory name+type.
If you insist on this please provide the doc strings you would like them to have.

[meooow25]

@treeowl do you still want to add doc strings?

[treeowl]

I'll try to write one for compareTips by tomorrow night. But otherwise I guess you can merge and I'll open an issue to remember.

[meooow25]

I'll go ahead and merge it then.

[treeowl]

Please add a haddock string.