World: r4wp

Yup. But that doesn't mean that I can switch to unsigned arithmetic. 
For that matter, sometimes switching to unsigned arithmetic means 
mostly indices at the top and bottom of a large range, skipping the 
middle (basically what you'd have to do with the Python model). By 
"large" I mean allocating a 2GB series or more and only using the 
100MB or so at both ends. Not always a good idea.

If you don't want to be hit by the pick 0, you can stay at head position 
of the series cannot you?

You can stay at the beginning of the series if you add the base offset 
to every calculated index reference. Bad idea in REBOL, too slow, 
but maybe Red's optimizer will be smart enough to undo that calculation. 
How many algebraic transformations will the optimizer be able to 
handle?

For that matter, in R3 (where I don't get caught by the 0 hole for 
PICK/POKE, just for AT) I have to do an offset-forward-by-one reference 
to avoid having to add 1 to every calculated index reference. Doesn't 
help in R2 though.

Hard to answer that now, but as the optimizing compiler will have 
a plugin architecture, it won't be limited, in the sense that you'll 
be able to add your own specific code optimizations, that if generic 
enough, could make its way into the official   repo. If the optimization 
processing time is short enough, it can be used for the JIT, else, 
it will be used only in for AOT compilations.

In that case, it would help if PICKZ/POKEZ were the actions because 
they don't have the 0 hole, and we can add PICK/POKE optimizations 
that apply an algebraic transformation to change the call to PICKZ/POKEZ. 
Implementing the hole in the action has overhead that the optimizer 
wouldn't be able to undo. It would be able to undo the hole implementation 
in a wrapper function though by inlining the code then optimizing 
it away. That would make up for the problems caused by putting the 
0 hole in there in the first place.

Though a type inference action-to-native transformation would help 
too :)

For PICKZ/POKEZ, we'll see if they still make sense once we come 
up with a global solution.

Most computed index situations use modulus, which generates 0-based 
numbers. If there's no 0 hole in PICK/POKE then you can do PICK/POKE 
NEXT, as long as this doesn't have side effects the way it does for 
port schemes or weird copy-on-write stuff; in that case PICKZ/POKEZ 
would be more of a convenience. If there's a 0 hole in PICK/POKE, 
you absolutely need a version of the functions without that hole, 
and having the extra advantage of being 0-based would be even better, 
an extra justification for their existence.

Keep in mind though that another occasion when you use computed indices 
with PICK/POKE is when you do stuff like s/(x) or s/(x): val, since 
path references for series should be using PICK/POKE internally.

One occasion where you use computed indexes is when you do C-style 
fake multidimensional array access. As with C, however, the math 
tends to be 0-based because of the modulus, so a 0 hole really hurts 
here. You can do these calculations much more easily if your base 
series position is 2 (or plus 1 * (dimension - 1) for each dimension) 
because the 0's go back one.

(sorry, there's two standard ways to pluralize index and I don't 
use either consistently)

Doc, Will you publish a Red/System standard function guide, listing 
all the functions, such as: print, print-line, length?, size?, zero?, 
form-type, ...

- "the most sane way to make a decision here is to come up with use 
cases": +1
- We are unlikely reach consensus: +1
- Have I ever been bitten by R2's behavior? No.


Great discussion on this. I greatly appreciate Andreas's points about 
common (-1, -2) cases, and his gist example. I'm good with throwing 
an error where silent incorrect processing would be worse. The concrete 
examples will be the best way to drive this, IMO. By concrete, I 
mean real-world, "this is code I actually wrote to solve a problem" 
stuff. If you can't post code for legal reasons, a generalized adaptation 
is almost as good. Make the most common uses behave correctly, even 
if there are cases they don't handle, and show how the other cases 
*can* be handled, even if it means slower mezz code. Then see if 
there's a better way to support them.

Why not have a special function to handle the 0 gap problem? The 
rest of the world can use the normal 'pick and 'poke and if you need 
the special ones they are available and behave as expected in those 
cases.

That's exactly what the suggested PICKZ / POKEZ are for.

I thought they only did the negative and zero index.

No.

Nope, they do the whole range, just 0-based.

Oh

If we are going to have a 0 hole, make it an error, not return none. 
A quiet error is worse than a loud one.

quiet errors are the worst.

Jerry: I don't have enough time for that, I am counting on the doc-strings 
and extraction tool to generate such documentation automatically. 
Peter is working on such tool.

I think that what we are seeing here is the frontier between academic 
and practical design choices. I am all for following academic principles 
as long as they are not 

too" detrimental to practical usage. I would draw the line at the 
point where most users would get lost. I believe that this is a dangerous 
pitfall in language design if you aim at a widespread use."

My feelings exactly

It's more of a "which is more useful" versus "which is less confusing 
for newbies". Best to find a balance.

As someone who is at say level 5 on the btiffin rebol scale what 
I am about to suggest may be stupid - if so be gentle :) Could we 
not create a different structure other than a series (an array or 
a matrix etc) that is 0 based and index driven and works like in 
most other languages for those who need that kind of usage?  Or could 
we introduce for series an index manipulation system such as this:s1/index: 
4, add s3/index 2, subtract s2/index 2, inc s3/index, dec s2/index, 
++ s1/index, s1/index: s1/index + off etc.

No, because at least for me, this is very common usage (just with 
different names):
>> b: [index 2 foo 3]
== [index 2 foo 3]
>> b/index
== 2

On a lighter note, Red seems to have something to do with basketball:

https://twitter.com/dreahenson/status/269031419706228736

Ladislav, REBOL doesn't have a naming convention that handles 0-based 
addressing.

 - actually, REBOL does have a couple of general naming conventions, 
 which, therefore, apply th the 0-based indexing as well

Negative indices being back from the tail of the series: please, 
no, never.

 - yes, this needs some analysis to find out what may be wrong about 
 that idea. The starting point may be that the series tail is "ephemeral" 
 in a sense as I noted, while the head is not ephemeral at all.

Indeed, any modification of a series changing its length, in the 
middle of a loop over a "reversed" view of that series, would most 
probably provoke errors.

Kaj: it seems to be restricted to basketball players with funny mustaches 
only. ;-)

:-)

Andreas wrote:

...disallow 0, have 1 return the next element forward, -1 the next 
element backward (R2)

 - I am sorry, but in my opinion this is actually not possible. Once 
 we disallow 0 (can be done) we have absolutely no right to use -1

Says who?

Whoever.1 is not preceded by -1 anyway.

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

And if you implement an index! type, you can make 1 be preceded by 
-1

I don't buy the "no right" argument. Romans had subtraction without 
0. It was a bad idea, but it was possible.

Ladislav, we don't need analysis on negative indices being back from 
the tail of the series. The concept only makes sense if you are only 
able to refer to a series from its head, thus negative indexes don't 
really have a meaning if you see the series as linear, so you decide 
to give negative indexes a meaning by looking at the series as a 
loop where the end wraps around to the beginning and vice-versa. 
If you are able to refer to a series frome a base position of somewhere 
other than at its head then you already have a meaning for negative 
indexes, and don't need to make up another.

frome -> from

We can do Roman indexes if need be. It's really bad for math, so 
we would need PICKZ and POKEZ if we want to do computed offsets (SKIP 
can have side effects with ports in cases where PICK/POKE don't necessarily 
have, but regardless it has overhead). Maybe Roman PICK/POKE will 
be easier for newbies to learn, though they may curse it later once 
they have to do anything hard. (Note: Roman in mathematical difficulty, 
not notation.)

Note that with R3-style bounds checking, the none value is considered 
to be roughly the same as a hole in the data. PICK past either end 
returns none. That means that PICK 0 returning none is basically 
a statement that there is a hole in the middle of the series that 
is just before the current position, and moves along as the series 
position moves along. 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.

At least triggering an error is easier to explain, it means that 
0 doesn't exist, like we're programming in Roman. It's (slightly) 
better than the 0 index existing but referring to a hole in the series 
(R2-style behavior).

Regarding returning none values against error... note this:
>> b: []
== []
in R2:
>> first b
** Script Error: Out of range or past end
** Near: first b
in R3:
>> first b
== none

Returning null in such a case is natural in other languages as well.

In zero-based REBOL it would not be possible to write:
for i 1 length? b 1 [print i]
but instead:
for i 0 (-1 + length? b) 1 [print i]

On the other side, here is quite nicely explained, why zero-based 
is better http://programmers.stackexchange.com/questions/110804/why-are-zero-based-arrays-the-norm