World: r4wp

With that background, I still think adding an ordinal! type is a 
nice solution. Here's the basic proposition:


1. introduce an ordinal! type, with literals: -3rd, -2nd, -1st, 1st, 
2nd, 3rd


2. extend PICK and POKE (and paths) to accept integer! and ordinal!

3. have SKIP only accept integer!, AT only accept ordinal!

4. define FIRST, SECOND, THIRD, etc as PICK 1st, etc

4a. maybe add dual FIRST-BACK (or use a /BACK refinement)


That in place, you keep all the nice "human-friendly" features of 
current R2, at the only expense of sometimes having to type 2 extra 
characters.

Andreas: how to you read -1st?

I personally would read it "minus first", but I think there are many 
other reasonable variations, such as "first to left", or "first back".

first to left

: that's how I read `series/-1` in R2...So if it's just a matter 
of making an implicit convention explicit, better just add a statement 
in the documentation than pay the cost of an additional datatype, 
no?

No, because you can't do that with just integers without severely 
messing up the computational aspect.

If you (ab)use integers to stand in for ordinals, you have to decide: 


- either "nice" ordinal behaviour (-1 preceding 1 for indexing), 
compromising on the integer aspect


- or "nice" computational behaviour (0 preceding 1 for indexing), 
compromising on the ordinal aspect

What do you think about the PICK/BACK option with only positive indexes 
(the most natural approach IMHO)?

Fine with me, but I think you will still want a method that allows 
you to used the full range of integers as computed indices.

That is another debate 1-indexing vs 0-indexing.

That is a third debate.

:-)

You will still always want a method for computed indexing with the 
full range of integers independently of whether that anchors at 0 
or 1.

Could be another refinement to PICK, such as PICK/FULL. Or a separate 
function. Or if you just PICKZ (or PICK/ZERO), if you want to add 
that

I think that such computation could be decorrelated from how you 
finally access the series element with the result of the computation.

Note that my proposal with the ordinal! datatype is also completely 
independent of 0-based or 1-based indexing.

FIRST/ZERO wouldn't look nice. ;-)

You wouldn't need that.

Right.

For _computed_ indices you only ever need PICK.

I still fail to see a real-world use-case where you need both negative 
and positive indexes at the same time (in other words, compute indexes 
*over* current position). Even in such rare case, you can still do 
the computation using INDEX? SKIP values (so switching to absolute 
indexes instead of relative ones).

R3 was optimized AFAIU specifically for this (extremely?) rare use-case 
over the very common cases for what R2 is optimized for (typically 
`series/-1`). So, could we find, at least one! use-case, where you 
need to compute indexes over current position (where R3 convention 
would prove to be better than R2).

If you disallow negative indices in PICK, it is quite dangerous to 
_allow_ them in paths.

I wouldn't allow negative integers in path in such case. I would 
either come up with an non-ambiguous syntax to handle path notation 
or forbid it too.

Ok, that's fine.

(forbid it too for integers <= 0)

(If non-positive integers were still allowed in paths, we'd just 
incompletely hide/obscure the problem.)

But in this case, s/-1st looks much nicer than any other syntax I 
can think of.

(If non-positive integers were still allowed in paths, we'd just 
incompletely hide/obscure the problem.)

That was never an option I've considered in such scenario.

Yes, I know :) I just wanted to have that explicitly mentioned again.

How about s/<-1instead of s/-1st?

Still prefer the latter.

Note also that in the PICK/BACK scenario, negative integers become 
available for a new possible usage, like addressing a series from 
tail (if that makes sense in a REBOL-like language). I know Brian 
is fully against that, but we need objective arguments to reason 
upon. "From tail" indexes are still a toy idea for me, until we can 
list all the pros/cons and see if it is an helpful addition or a 
bad idea.

Yes.

I basically prefer adding a datatype than adding a syntactic hack.

And basically, adding /< syntax would most likely add just another 
datatype :)

s/-/1 would probably be another more regular syntactic option.

It would be then one character-only shorter than: s <- 1 ;-).

But still rather hackish :)

Because now one logical path component is split up into two actual 
path components.

Agreed.

My Understanding of Series:

A contiguous collection of boxes sequentially numbered in ascending 
order starting at 1.
Each box can contain any rebol value
The head of a series is always box number 1

The last item in a series is always in box number (length? series)
The tail of a series is always box number (length? series) + 1

Any series can have multiple words referencing any box in that series 
resulting in a sub-series (but not a copy)

index? series - always returns the box number of the value referenced 
by series

Evaluating a word referencing a series returns the series from box 
number (index? series) up to and including box number (index? tail 
series)

index? is the only rebol word that directly uses the box numbers 
of the series

All other rebol words that manipulate series are relative to the 
box number of the word referencing the series

A series is empty when: equal? head series tail series => true – 
or – when all boxes are empty

Examples:

s1: [a b c d e f g h i j]  => creates 10 boxes numbered 1 to 10 from 
the left with a in box 1 and j in box 10 – unseen is box 11 which 
is 'tail as seen by: index? tail s1

s2: at s1 3 => references s1 starting from box 3 of s1 - [c d e f 
g h i j]

s3: at s2 4 => references s1 starting from box 6 of s1 - [f g h i 
j] which is item 4 of s2

probe index? s1 => 1
probe index? s2 => 3
probe index? s3 => 6


probe head s3 => [a b c d e f g h i j] - showing that s3 references 
the same series as s1

probe pick s1 2 => 'b
probe pick s2 2 => 'd
probe pick s3 2 => 'g


probe s3/-2 - this is shorthand for back back s3 or pick s3 -2 (the 
negative number simply means move back twice) => 'd

probe tail s1 => []
probe tail s2 => []
probe tail s3 => []

forall s2 [prin first s2] print => cdefghij
forall s3 [prin first s3] print => fghij

probe index? tail s1 => 11

Possible SOLUTION:

So, what is missing? Words that directly manipulate the box numbers 
(index)? – so maybe we need something like this:

s1/index: 4 => sets the index of s1 to 4 and causes word s1 to reference 
the series starting from box 4

add s3/index 2 => adds 2 to the index of s3 causing s3 to reference 
the box 2 places further on => 'h

add s2/index -2 or subtract s2/index 2 => subtracts two from s2's 
index causing s2 to now reference box 1

You can now use any mathematical operations on the index of a word 
referencing a series as long as it results in an integer in range

If index? series > (length? series) + 1  or index? series < 1 then 
an "index out of bounds" error should result
Zero is a non-issue because it has no meaning in a 1 based series

This kind of shorthand: s1/-3 becomes redundant - but if kept still 
means: back back back s1

probe s3/-2 - this is shorthand for back back s3 or pick s3 -2 (the 
negative number simply means move back twice) => 'd


That is the interpretation you can make in R2, but it is no more 
valid in R3.

I honestly think there is so much confusion over this because we 
are trying to merge together two different "concepts". Concept 1 
is a series which is traversed as in Rebol 2 and whre s/-2 is shorthand 
for back back s. Concept 2 is a 0 based sequence which is traversed 
via index manipulation. The concepts need to be kept seperate even 
if they are applied to the same set of contiguous boxes. The only 
way to do this as far as i can see is to develop a set of index manipulation 
functions in addition to the existing series traversal functions. 
The concepts can then be easily taught to newbies and gurus can mix 
and match to their hearts content.

If anything, s/-2 is a shorthand for `FIRST back back s`.

Andreas - yes - agreed

Whereas s/2 could be conceived as shorthand for `first next s`. And 
there you already get a glimpse at the problem:

- s/2 is first next s, s/-2 is first back back -- why is there 1 
next but 2 backs?
- what is s/0?

There is no 0 by convention - that is what defines the "concept" 
of  series traversal. Arrays are traversed by index manipulation 
whether 0 based or not..

Concept 2 is a 0 based sequence which is traversed via index manipulation.

That interpretation doesn't match `FIRST s` and `PICK s 1`...

Yes but Frst s and Pick s 1 are series functions - not index manipulation 
functions - different concepts - first s in index system would be 
s[i]

the 1 in `pick s 1` sure awfully looks like an index to me :)