Generic TUPLE!, Sequence Compression, and Predicates

[hostilefork]

This is a major change which has been on the radar for some time. It makes TUPLE! a type that is generalized and able to store WORD!, INTEGER!, BLOCK!, GROUP!, TAG!, and TEXT!.

The specific case of INTEGER!s separated by a period is kept for DECIMAL!. A future change will unify PAIR! and TUPLE!, such that a 2-element TUPLE! of integers renders as 1x1 instead of 1.1

As with paths, BLANK!s in TUPLE! do not render. This means .not.even? is a 3-element TUPLE! with a BLANK! in the first slot, and then two words. For now, the ambiguous representations of .1 and 1. are set to raise errors, and should be changed to 0.1 and 1.0 for DECIMAL! usage. A decision on the ultimate choice for this will be made later after TUPLE!s have been around long enough to have staunch defenders of keeping them general.

An obvious change is that . is no longer an ordinary WORD! character. This means any code which used WORD!s with dots in them will have to change to something else (e.g. a hyphen) or make what's on the left of a dot an object. However, if the word form was just being used for rendering, it should still convert TO TEXT! the same.

Alternate DATE! forms like 20/Oct/2010 are now PATH!s, so you need to use 20-Oct-2010 if you wanted a DATE!. This opens up more PATH! forms including fractions like 1/2.

While BLANK!-headed paths are called "refinements", this proposes that BLANK!-headed tuples be commonly known as "predicates". How predicates work is outlined in a forum post from January 2019...this commit includes a proof-of-concept:

>> x: [2 4 6 8 7 9 13]
== [2 4 6 8 7 9 13]

>> until .not.even? [take x]
== 7

>> x
== [9 13]

Several optimization points are addressed in this PR. This includes the longstanding wish that PATH!s like /foo not cost any more than the ANY-WORD! refinement of R3-Alpha...e.g. they fit entirely in a cell and cost the same as a WORD!. That applies also to foo/, .foo, and foo.. When TUPLE!s or PATH!s consist of byte-sized integer values, they are also compressed into the cell itself.

The shaky scanning tweaks that permitted PATH! forms like foo//bar in the past have been updated to be more robust. However, the scanner is still more "organic" than it should be...and would benefit from a state-machine-based rewrite.

There are a few tests still to sort out, but by and large the change appears to work...and so it's time to start absorbing its effects.

[giuliolunati]

I llike that! I wish:

(to-date 2020/10/5) = 5-Oct-2020
(to-decimal 1/5) = 0.2

[lkppo]

Le 06/10/2020 02:44, Hostile Fork a écrit :

Alternate DATE! forms like 20/Oct/2010 are now PATH!s, so you need to use 20-Oct-2010 if you wanted a DATE!. This opens up more PATH! forms including fractions like 1/2.

Just follow ISO 861 and remove surprise.

-- Stéphane Aulery

[hostilefork]

@giuliolunati - I put in the fraction conversion, it sounds like there's desires in general for some date redesigns.

@lkppo hello, good to see you're still around.

I've made a forum post where I'd like to see some code examples "before" and "after" the kind of change that might be envisioned. Now that the generalized PATH!s work better it should hopefully be possible to make some demos.

and generalized TUPLE! is merged... I've got a backlog of other things to look at, but let me know what issues come up.