We need a coherent generic TUPLE!. But being fully generic is obstructed as people do not want to let go of 6.28 being a DECIMAL!

Dots in tuples are *mostly* non-negotiable Not that I'm too concerned about representing IPv4 addresses accurately, or that I think colors represented as 255.255.0 are all that important either. It's the higher purposes I have in mind that are more concerning **foo,bar: 10** just doesn't have a good look and feel to it. **foo.bar: 10** does. That just happens to mesh with the fact that 1.2.3.4 looks better than 1,2,3,4 for purposes of an "atomic" value.

## We can solve it by unifying PAIR! and TUPLE!

PAIR! can exist, but as a *type constraint*. So **pair?** tells you if you have a tuple of length 2. We need to rig up ways to do type tests like this in function parameters and such, so we use whatever that mechanism is to make PAIR! work for that.

If you have a two-element TUPLE! and its first and second items are numbers, you get an `x`

instead of a dot:

```
>> to tuple! [1 2]
== 1x2
>> to tuple! [1 foo]
== 1.foo ; second isn't a number, so no conflict
>> foo: 10
>> compose (foo).20 ; I'll have lots more to say about the power of this
== 10x20
```

Then we only have to worry about two more case, which is what to do when a tuple is blank in the first spot but has a single integer in the second. Or blank in the second spot with a single integer in the first.

We can't use x in this case, nor would we want to:

```
foo: 10
>> compose .(foo)
== x10 ; collides with variable named X10
```

So this means a small sacrifice for the math heads: **0.5 and 5.0 are DECIMAL!, but .5 and 5. are TUPLE!**, just as /5 and 5/ are PATH!. If you're building some tabular data where you like the idea of having **.5** and **5.** be shorthands for numbers then go ahead, you'll just have to use TO DECIMAL! on them before you perform math on them.

So we sacrifice one tuple form and get the nice historical PAIR! look out of it. The result is a full spectrum answer for TUPLE!. Like PATH!, it can hold any number of WORD!, INTEGER!, BLOCK!, GROUP!, or TEXT! ... where the number of items is greater than 2.

There will be compression methods to take advantage of with single-item ANY-TUPLE! and ANY-PATH!, as well as two-item cases, or cases where they are all byte-sized numbers. There will be no length limit (e.g. no MAX_TUPLE)... if you exceed what can be stored in the cell, it will just make a series to store the data. Lots of opportunities opened up since TUPLE! and PATH! are top-level immutable...and COMPOSE is going to be *great*.