World: r4wp

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 :)

But, agreed, Ken. That's basically the same distinction I keep trying 
to make, by separating ordinal access from other possible accesses.

The 1 in Pick s 1 is not an index it is an offset from s

if s is at box 4 in the original series then pick s 1 returns the 
contents of box 4 not box 1

In an index system if you want box 4 you say s[4] - or if your current 
index is at 1 and you want box 4 you say s[i + 3]

Andreas - the problem I have with ordinals is how do you do mathematics 
on them eg. 3 + -3rd ? Index manipulation uses ingteger! and so is 
mathematically modifiable

Anyway - good luck Doc on sorting this one out - and thanks again 
for doing Red it is very exciting

I like Andreas' proposal

Ken, re maths for ordinals: just a matter of how you want to define 
it.

-3rd + 3 == 1st

1st -1 = -1st, -1st + 1 = 1st, 1st + 0 = 1st

The more interesting question is how ordinals map to integers :) 
That basically requires a decision of how you want to do indexing 
with integers, then it's easy as well.

One possibility. Another would be to have ordinals purely as syntactic 
convenience, and not allow arithmetics with them.

Ok - thanks for the clarification Andreas - that makes sense now. 
I think maths usage would be essential for use cases such as the 
one Brian put forward - he mentioned at least addition and modulo.

Anyway - I have shared what I felt I needed to say. I will now leave 
it to the guru's to decide the way forward on this matter. My knowlege 
of Rebol is not sufficient to push any particular solution.

It's just a dialect for going in the opposite direction

 - it is not, in fact. (PICK SERIES INDEX) is just an evaluation of 
 a function, not a "dialect"

I don't buy the 

no right" argument. Romans had subtraction without 0. It was a bad 
idea, but it was possible." Yes, but -1 is not "subtraction", it 
is a value.

Now, try to come up with a way to explain to newbies that this phantom 
hole in a series makes sense, or is a good idea.

 - yes, a good illustration from a beginner/documentation/education 
 POV. Also, what is exactly as bad even for experienced users is that 
 it disrespects arithmetic making simple index arithmetic (ADD INDEX 
 OFFSET) not usable.

...it means that 0 doesn't exist, like we're programming in Roman.

 - again, a cute formulation. I bet that there is no "programming 
 in Roman", the word "algorithm" is from the world where 0 does exist.

Kensingleton: thank you very much for your inputs. Having different 
point of view is helpful.

It's just a dialect for going in the opposite direction" - it is 
not, in fact. (PICK SERIES INDEX) is just an evaluation of a function, 
not a "dialect""

False. PICK SERIES INDEX is usually evaluated as DO dialect. It could 
also be evaluated as any other dialect

SERIES/-1 is not even function evalutation in the DO dialect, it's 
path evaluation

Also, what is exactly as bad even for experienced users is that it 
disrespects arithmetic making simple index arithmetic (ADD INDEX 
OFFSET) not usable.


I guess you're not talking about R2, which index arithmetic has proven 
to be very usable in last twelve years (at least) through countless 
*working* user apps.

My Understanding of Series:
A contiguous collection of boxes sequentially 
numbered in ascending order starting at 1.

 - this is correct only for series I would call "Head Series", i.e. 
 such series that are their own heads.

Agreed, "not usable" is a little harse. Bad and awkward, but once 
you work around that it is usable.

harse -> harsh

I guess you're not talking about R2, which index arithmetic has proven 
to be very usable in last twelve years (at least) through countless 
*working* user apps.

 - "working" are only the ones limiting the index arihmetic to some 
 special cases. Those not limiting themselves to such cases are not 
 working.

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

... have to know* that you have to work around it ...

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

 - yes, "you have to work around it" is (for me) a different formulation 
 equivalent to "not working"

I am able to do any work-arounds necessary at any time. However, 
I prefer to use a working solution.

Knowing Carl's preferences, I did not insist on switching to 0-based 
indexing. However, for the sake of arithmetic, I at least convinced 
him to switch to "continuous indexing".

Here is a task I consider relevant:


1) define a function obtaining a series S and an index I and yielding 
an index J such that PICK S I would be equivalent to PICK HEAD S 
J
1a) do the task in R2
1b) do the task in R3
1c) do the task in R4 with zero-based indexing

This is my solution of 1c):

head-index?: func [s [series!] i [integer!]] [i + index? s]

(that is what I call "working index arithmetic")

This is my solution of 1b):

head-index?: func [s [series!] i [integer!]] [i - 1 + index? s]

(again, a case of "working index arithmetic")