World: r4wp

The reason I'm not finding negative indexes in paths in my own CMS 
code is that I had to replace them because they're not compatible 
between R2 and R3

If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices

 - if I know you well, you would actually explain to them the advantages 
 of the simple approach (especially when being asked about some index 
 arithmetic problem), and I am sure that the "reasonable souls" would 
 join you soon, and the others would either stop programming in the 
 language or follow suit as well.

Hopefully :)

I'm not bothered by the zero hole, but I was bothered by R3 being 
incompatible

I was bothered by them not fixing AT in R3 as well. There's a lot 
wrong with R2.

Bug-for-bug compatibility is overrated. But if the 0 hole was restored 
to R3, as triggering an error, I would be more than happy to have 
R2 trigger the same error.

..but you did...?

 - people do crosswords, sudoko and play mindless computer games too.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s]]]


This should also return none if i is 0, which replicates the hole.

Wait, it's supposed to return the index, not the result.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s] i = 0 [0]]]

The hole roams with the position of s, so the result would be a constant 
regardless of that position.

Welcome to R2 index arithmetic :-/

Yes, Brian is right, that is R2 index "arithmetic", the only problem 
is that CASE is not "arithmetic", as you might have guessed.

That is the "broken arithmetic workaround" that can be used. However, 
my point was: "Why use the broken arithmetic and make common people 
unable to solve this task, which should be actually trivial for anybody 
to solve?". Kaj's answer to this question above actually is: "because 
its intended audience is common people". Phew!

You keep ignoring the ordinal! solution

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

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


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Excellent. With such a simple solution, even ordinal! seems excessive

Doc, I can splint a broken leg but it doesn't make it less broken. 
Still, you're lucky thet you haven't been caught by this.


As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work. If PICKZ and POKEZ are available, those of us who need something 
that works will have something. I don't mind even making R3 work 
like this, but only with the error and the alternate working functions. 
Let the people who insist on using path notation bear the brunt of 
the problem, so be it.

Same with x/0.

Of course path notation should still work on maps and other things 
where it means SELECT, not PICK,

Great discussion on this. I'll just say that "s/-1st" doesn't read 
well to me.

Yeah, s/-1 is better.

for pure arithmetic efficiency, as you've showed

 - actually, it is not for "pure arithmetic efficiency", it is for 
 users to be able to "naturally" work with it! Even Carl is unable 
 to use it without errors when it is too contrived, which demonstrates 
 that efficiency is not everything to consider.

Brian showed that R2 is not 

broken" as the head-index? function can be written." - Carl demonstrated 
(on his own bug) that it *is* broken, and what is broken is not "R2", 
what is broken is the index arithmetic, as Brian's example clearly 
demonstrates (you need to use CASE, index arithmetic cannot be used).

According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases.

 - as opposed to that, my opinion is that the HEAD-INDEX? function 
 represent an, "extremely simple" use case that everyone should be 
 able to solve without having a specialized training to be able to 
 do so.

Instead of throwing error on pick 0, can I propose adding undefined! 
datatype? In ActionScript, which I use quite often last days you 
can distinguish not defined and null values like:
	var a:Array = new Array();
	a[1] = 1;
	a[2] = null;
	log(a[1], a[2], a[3]); //<-- would output: 1, null, undefined

Btw.. I think it was me who asked Carl to implement path notations 
with parens allowing to write b/(n) It's in REBOL since 2.6.. sorry 
if it's causing confusion.
http://www.rebol.com/docs/changes-2-6.html#section-8

For example, when traversing two series at the same time while using 
just one index variable (which is pretty common), you need to be 
able to use the variable to correctly point to the corresponding 
places in both series, which logically *needs* some version of "index 
arithmetic".

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

 - however, this does not do what was requested, the number obtained 
 does not have the required property!

Oldes, undefined! is unset! in REBOL. I like the option to use parens 
in paths, so no harm done :-)

(what is interesting is the fact that when you rely on this, you 
get "kicked in the butt" like Carl was)

Probe with unset! is, that one cannot work with that in the most 
cases.. it would just move the error somewhere else.

(problem.. like:
>> f: does [] probe f
** Script Error: probe is missing its value argument
** Near: probe f)

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

Excellent. With such a simple solution, even ordinal! seems excessive

 - OK, since Kaj named the solution "simple", I can agree that (and 
 never questioned) that SKIP SERIES I is a good operation to use and 
 that really produces the simplest possible:

(PICKZ SERIES I) ?= (PICKZ SKIP SERIES I 0)

Otherwise, the whole nonsense of "ordinal datatype" just buries the 
whole thing under another pile of excessively complicated crap

Still, you're lucky thet you haven't been caught by this.
 - actually, he has been, just above he wrote:

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

, which caught him completely

(it proved he has no idea)

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work.

 - if PICK SERIES 0 yielding NONE is stupid, then triggering an error 
 is not less stupid

I should have said that it is not significantly less stupid.

In no way it is simple, for sure.

...and I still dislike the "PICKZ" name, although I am able to live 
with it...

So the correct version of Doc's solution is even shorter:

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

The only value for which this is not equivalent is 0, but that's 
an invalid index, anyway

Now we see why AT is designed with a discontinuity: to compensate 
for the discontinuity in indexes

To insist that AT should be mathematically correct, leads to indexing 
being broken

It seems prudent to me to explain this essential function of AT in 
its documentation

So the correct version of Doc's solution is even shorter:

head-index?: 
func [s [series!] i [integer!]] [index? at s i]
 - wrong again

Can you give an example?

aha, you wrote it as well, "The only value for which this is not 
equivalent is 0"

Yes, so outside the range of validity of the function