World: r4wp

Yes, that's also R3's behaviour.

Back to the start again? :-)

Here is a new proposition for solving the "PICK issue":

1) Forbid <= 0 indexes.


2) Add a PICK-BACK action that will take only positive integers, 
PICK-BACK series 1 would return the first element on the left of 
current series position.


3) As PICK-BACK is not a very nice and concise name (I like actions 
to be named with a single word), an op! alternative would be provided: 
<- (opening angle-bracket followed by a dash aka "ASCII arrow")

Examples:
    >> series: next [A B C]
    >> pick-back series 1
    == A
    >> series <- 1
    == A
    >> series <- 2
    == none			;-- to be consistent with out-of-bound PICK


For path notations options in such scenario, I'm open to propositions. 
So what are the pros/cons of such solution?

In forbidding indeces < 1 would none be returned or a runtime error 
raised?

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 ;-).