World: r4wp

Seeing as the use cases for accessing elements before the 'HEAD appears 
to be quite rare, couldn't pick-back be left as a "mezzanine":

pick-back: func [ser index] [pick skip ser negate index 1]

A runtime error. Having it as a mezz could be a good option.

Having it as an action would make it much faster when interpreted 
instead of compiled.

As for naming wouldn't a refinement be better?

pick/back series pos-int

Maybe.

Probably. :-)

That could also work for FIRST/BACK.

Doc, the above proposition makes sense if you *also* have a contiguous 
PICK function which you can loop on from negative to position without 
gap (like R3).  I'd use a PICKZ  to eliminate the "0" weirdness from 
the discussion, in that case.

Part of the reason why I keep highlighting the ordinals aspect is 
that I think this is part of what many people really like about current 
R2 behaviour, and many fear to lose.


FIRST is convenient and nice, and having path notation for "first-to-right", 
"first-to-left" is nice as well.

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