support sorting tuples

[nsajko]

Uses merge sort, as an obvious choice for a stable sort of tuples.

A recursive data structure of singleton type, representing Peano natural numbers, is used to help with splitting a tuple into two halves in the merge sort. An alternative design would use a reference tuple, but this would require relying on tail more, which seems more harsh on the compiler. With the recursive datastructure the predecessor operation and the successor operation are both trivial.

Allows inference to preserve inferred element type even when tuple length is not known.

Follow-up PRs may add further improvements, such as the ability to select an unstable sorting algorithm.

The added file, typedomainnumbers.jl is not specific to sorting, thus making it a separate file. Xref #55571.

Fixes #54489

[KristofferC]

The complexity of this code makes me kind of uncomfortable, especially the typed natural number stuff.

How about copy pasting the SortedNetwork implementations up to length 16 and then allocate above that?

[nsajko]

the typed natural number stuff.

FTR the type domain numbers are applicable to other places, too, I'll be putting up more PRs relying on that code. Also, it's not like there's any complex logic there, it's mostly just unconvential, I think. That reminds me though, I didn't add any tests for type domain numbers here.

How about copy pasting the SortedNetwork implementations up to length 16

1. That wouldn't be a stable sort. (As far as I remember, stable sorting networks are actually possible, but bigger/less efficient than unstable sorting networks.)
2. The current code supports lengths up to 31. And arbitrary lengths in principle, with some adjustment.

[adienes]

it kind of feels like the sorting stuff here is just a facade to sneak in the (previously rejected) type domain number stuff

[nsajko]

Are you trying to be inflammatory or something? Do you really have to do that here, in the PR discussion?

[adienes]

given that you closed #55571 with the comment

I guess I'll try making the next PR more minimal, in the sense that only methods that are necessary for a specific improvement somewhere in Base will be included, then if that PR gets merged I'll try following up.

I guess the adjective I would use is "observant"

[nsajko]

I'll bite, what's your point?

[mcabbott]

I agree this seems like a lot of code, compared to these 20 lines which handle NTuples in #54494 . What exactly is gained, in what use cases? It seems you claim better inference, can you show examples where this matters?

How about copy pasting the SortedNetwork implementations up to length 16 and then allocate above that?

I assume this refers to https://github.com/JeffreySarnoff/SortingNetworks.jl , which writes out the steps for each length. That also seems attractively simple.

[nsajko]

The benefit is that this supports Tuple, while that PR just supports NTuple.

I assume this refers to https://github.com/JeffreySarnoff/SortingNetworks.jl , which writes out the steps for each length. That also seems attractively simple.

As I said above, that can't be the default sort because it's not stable.

[LilithHafner]

The benefit is that this supports Tuple, while that PR just supports NTuple.

It would be trivial (though IMO a bad idea) to make #54494 support non-homogenous tuples.

[nsajko]

It would be trivial (though IMO a bad idea) to make #54494 support non-homogenous tuples.

Of course, but not with good inference.

[jakobnissen]

Do we even want to be able to sort tuples? It makes me a little uncomfortable that it's wildly type unstable to sort e.g. Tuple{Float64, Int, Int}. While this may be obvious for seasoned Julians, I worry that it will make it too easy for unexperienced programmers to accidentally create 100s, or 1000s of new types in their codebase which makes specialization explode.

[KristofferC]

Indeed, I think sorting of non-homogenous tuples has very little practical use.

[vtjnash]

Indeed, I think sorting of non-homogenous tuples has very little practical use.

I would support bringing back the PR that made it easy to sort arbitrary iterables, since in this example it would give the ability to be type stable (eltype of that Tuple is type stable), so the resulting sorted object would be both fast and reliable

[KristofferC]

I would support bringing back the PR that made it easy to sort arbitrary iterables,

That feature has already been discussed, tuple sorting can clearly be made withiut the requirement that arbitrary iterators can be sorted.

[stevengj]

See also #31818, which points to the static sorting algorithm in TupleTools.jl