World: r4wp

One very important point is, I think, that this discussion is not 
necessarily about 0-based vs 1-based.


It is more about if and how to map the concept of ordinals to the 
concept of integers. If you choose to use indices-as-ordinals ("1-based 
indices"), those two questions collapse to one. If you choose to 
use indices-as-offsets ("0-based indices"), the question of how to 
handle ordinals _still remains_.

We not only have to think about the use case of "give me the first 
element", but also about "give me the element 2 steps after that 
other element" or "how many elements are in between two other elements".

One reason I posted the Pascal example was due to the earlier discussion 
about  ordinals not including zero. In Pascal, integer are considered 
an ordinal type and include zero. Now the Pascal definition of ordinal 
may not be absolutely correct in mathematical terms but I would suggest 
it is pragmatic to support reasonable behaviour for indexing.

I don't see quite the same distinction as you between indices-as-ordinals 
and indices-as-offsets except in terms of implementation where the 
former requires additional steps in the calculation compared with 
the latterr. (Though as you say this is not the issue).

So am I correct in that the issue is more the mixing of absolute 
indexing with  relative indexing?

== "123456789"
>> index? ser      
== 1
>> ser: next ser   
== "23456789"
>> index? ser   
== 2
>> pick ser 1   
== #"2"

So would two sets of functions, one providing absolute addressing 
and the other providing relative addressing solve the issue?

Not really. You would still need to clarify the semantics for how 
the relative addressing should work.

If it is allowed to use integers in relative addressing, you will 
have to define what ought to happen for non-positive integers.

As in 

>> pick ser -1
== #"1"

And `pick ser 0`, yes.

Which I guess is back wehre the discussion started.

Exactly :)

Well at least I understand the issue a little better :-)

Ada and VHDL/Verilog are two other languages that spring to mind, 
which allow choosing the index range, like Pascal.

But I guess they are all absolute addressing rather than addressing 
realtive to a current position? I believe Pascal is.

One thing I always find interesting about definable range of Pascal, 
is that Wirth later moved on to fixed, 0-based ranges for arrays 
in Oberon.

Yes I noticed that.

Is it true to say that whilst there is no effective difference (in 
logical terms) between 0-based and 1-based absolute indexing, there 
is a difference when it comes to relative indexing,

The difference being how to handle zero.

Basically that's fair to say, yes.

I feel that there is a consitent way to look at 1-based relative 
addressing but only if you consider 0 to be the position immediately 
before the current position.


It is to define the given index as an offset from 1 (the current 
position). (Examples using current position as absolute index 5 [1-based])


index 10 would be calculated as offset 9 positions from the current 
position [absolute 14]

index 1 would be calculated as offset 0 from the current position 
[absolute 5]
index 0 wold be offest -1 from the current position [absolute 4]

index -1 would be offset - 2 from the current position [absolute 
3]


I know that most people will see this as a kludge or don't like it's 
different behaviour to REBOL2.

On the other hand, it can be explained in a consistent manner.

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.