World: r4wp

In the short article, there's also some experience with early programming 
languages ...

btw - will Red have range! datatype? And would it influence the way 
we look into series, positioning, indices, etc?

Completely agreed 0 does not exist, even not for computers. A computer 
with 0 memory does not have memory at address 0 either :)

Counting starting at 0 is nonsense. No matter who and how many times 
it is explained. In human/fysic world we only put letter 1 in envelope 
1, letter 2 in envelope 2 etcetera, there is no letter 0 to put into 
envelope 0. It is only a confusing trick to start at 0. (I know you 
can look at memory like a binary tree) In these days of plenty of 
memory, I say let location 0 unused. Besides for who was REBOL meant 
initially? People. Scientists not computerscientists. Let those struggle 
with C and the likes. 1-base is one of the big plusses REBOL has 
over the majority of other languages. (enough bikeshedding from me 
today)

Yet those ppl use arguments, like even in Bibble, there was zeroth 
day (well, in physics, that might mean the singularity point, where 
our physic laws don't apply), or, that without 0 you are not able 
to count BC to nowadays difference properly. Whoever came with that 
BC AD distinction, was not sane at the first place, and I really 
doubt, that back at those times, they agreed that their age is some 
-2300 years, knowing the point 0 (Christ) ahead :-)

Please move the discussion whether "0 exists" elsewhere. REBOL's 
integer! corresponds to integers and includes 0. Unless you want 
to change that as well, that's a fact we have to live with.

Default base index in programming languages: 

http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Array%5Fsystem%5Fcross-reference%5Flist


Notable languages with 1-based indexing: FORTRAN, Lua, Mathematica, 
MATLAB, Smalltalk.

Andreas - stop pesking us for such a chat. Many arguments areound 
are based upon various arguments, some of them leading to history 
of mankind/math itself. Thanks ...

Pekr, please chat elsewhere.

Range! datatype: I would like to add one, but it needs preliminary 
study on how it can affect series semantics.

Whilst Pascal allows arrays to have a user specified base for array 
indeces, the default is 1 based. It also allows a zero element:

Code
program Arrays;
uses SysUtils;
var
  i : Integer;
  myArray : Array[-1..1] of Integer = (1,2,3); 
begin
  for i := -1 to 1 do

    writeln('Element ' + IntToStr(i) + ' Value ' + IntToStr(myArray[i]));
end.

Result
Element -1 Value 1
Element 0 Value 2
Element 1 Value 3

An interesting point of view on zero v 1 based indexing - http://alarmingdevelopment.org/?p=470

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?