World: r4wp

My thought behind the "tail position" complaint above was, that series, 
position, and index are already used rather exchangably, and lax 
in a few parts of REBOL's documentation. Adding "tail position" to 
the mix, only further contributes to that confusion.

As "tail position" severely weakens the definition possibilities 
for "position".

Yes, the nomenclature problem...

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

Moreover, something like "the head position" is actually a "permanent 
characteristic", while "the tail position" is in a sense "ephemeral" 
as demonstrated by the following:

block: [a b c]
pos-a: head block
pos-b: next pos-a
pos-c: next pos-b

; now, POS-C is not tail
tail? POS-C ; == false
remove back tail block
tail? POS-C; == true
append block 'c
tail? pos-c ; false again

, while the POS-C is not ephemeral, continuing to exist no matter 
what

Maxim, unfortunately this does not help at all, because we have no 
built-in way to compute with those vectors.

exactly.  we don't have an index! type.

My note to Max's contribution:


- in REBOL, blocks of length 0 are not "impossible", that is, we 
have to use a nomenclature compatible with this fact

The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.

 - it may not be a "weird inconsistency", but it is almost imposible 
 to describe to a newbie in a reasonable way

empty blocks are not impossible to describe.  but all functions will 
provide special cases to manage them (return another infinitely small 
block or none, or raise an error) because as such, they are vectorially 
equivalent to null.    an empty  block is just a starting place without 
any room to move.  when only looking forward, it is exactly the same 
as the tail (when you read my original post) and hence in actual 
code, tail [1 2 3] and  [ ]   are exactly the same, if only positive 
indices are being used.

Too many constraints.

REBOL allows you to look backwards, REBOL allows you to use negative 
indices.

As such R3's model is actually not only _not_ "weirdly inconsistent", 
but actually more consistent than R2's model, when having to use 
in-language properties to describe it.

Yes, Andreas, but I am not the one willing to explain to newbies 
"Why 0 'points backwards?"

I am still sure that once we have negative numbers, we cannot do 
without zero (to maintain compatibility with the continuity of the 
underlying series). Then, actually, the SKIP behaviour is the only 
one easy to describe and use as the base of the "nomenclature".

Ladislav... what about adding another helper function: last? pos-c 
== true :-)

Ladislav, I fully agree. I don't think that "0 points backwards" 
is particularly elegant either, but I'm willing to explain it ("0 
points to the element before 1") and find it much better than having 
to explain when and why you have to very careful with computing indices, 
or even debug (R2) code that was written unaware of this fact.

No problem, but that is also and "ephemeral characteristic" exactly 
like TAIL?

The only other realistic option I see, is to disallow negative indices-as-ordinals 
completely (but still keep the possibility to use negative indices-as-offsets, 
such as in SKIP or BrianH's proposed PICKZ/POKEZ).

(I meant that LAST? is as ephemeral as TAIL?, while HEAD? is not 
ephemeral at all)

Anyway.. reading this discussion, I'm feeling like deja vu... I would 
stay with REBOL way of indexing. Although I don't have any problem 
to switch into 0-based indexing in other languages. The problem is, 
that the other languages don't have functions like next, back, tail.. 
which enable series traversing, do they?

Keeping negative indices with R2's weird behaviour only for the convenience 
of being able to write "foo/-1" is not worth it, in my eyes.

Oldes: C does have pointer arithmetic, which is, in many ways, isomorphic 
to SKIP

Keeping R3's behaviour is certainly a possibility.

Oldes: next/back/tail/etc would work just as fine with indices-as-offsets 
("0-based").

Andreas: what do you propose to replace "foo/-1" if negative indexes 
are disallowed? "first skip foo -1"?

anyhow I always considered negative indices to be a bad idea.  I 
find SKIP and BACK convey much better meaning, because they are inherently 
directional (vectorial) by nature.  


IMHO  negative indices should have been implemented like in python, 
where they count from the tail, rather than "curren" position.   
they are MUCH more useful, they would be used daily by me (and most 
rebolers) in such a case.

I was thinking about high level languages. For pointers is 0-based 
indexing logical.

foo/-1    ==    skip tail foo -1

Maxim, that does not correspond to current R2/R3 behaviour. We are 
talking about indexing "backwards" from the current position.

(But I also prefer Python's behaviour :)

DocKimbel: yes, either `first skip foo -1`, or `pickz foo -1`, or 
`foo/-1st`.

I somehow incline to R2's behaviour just with error instead of none 
for 0's index

And no error for out-of-bounds indices?

To me, the description here http://www.rebol.com/docs/core23/rebolcore-6.html#section-1.1
is logical, but I'm not a scientist.

Andreas: what do you propose to replace "foo/-1" if negative indexes 
are disallowed? "first skip foo -1"? - In 1-based indexing without 
negative values it should be PICK-BACK FOO 2, in fact, which is awful

it can still change for R3... very little code uses negative indices. 
 


 its already incompatible with R2, so we might be better off finding 
 the proper incompatibility than trying to "wing it" in the name of 
 continuity.   same for Red, it is free to be better than its pre-decessors. 
    


python's  negative indices where a revelation when I used python. 
 It was one of the very few redeeming features I found it had.

I use pick ONLY in case where I don't want to get error if I'm out 
of bounds

Ladislav: I would still keep offset-based SKIP.

hm.. now I see, that even select and path notation is not returning 
error.. so I don't know where I came to this.

Yes, I just explained what should be used instead of PICK FOO -1

I'd rather add an offset-based PICKZ than a PICK-BACK :)

(when being consistent, that is)

Andreas, I understand, I was just showing the consistent usage of 
1-based indexing without zero

Could also be `pick skip foo -1 1`, but that is not less awful.

Could also be `pick skip foo -1 1`

 - yes, but that is not the direct equivalent of (inconsistent) PICK 
 FOO -1

Yes.

Of PICK-FORWARD 1 returns the current value, PICK-BACKWARD 1 should 
of course also return the current value.

If*