World: r4wp

perhaps one other way to look at this problem is to only have positive 
indices, and have REVERSE (or similar) return a value that is not 
a copy or modification of the series, but simply lets you look backwards.


At first look, the implementation overhead wouldn't be high for supporting 
such feature and that could solve our PICK issue, elegantly I think. 
My only interrogation about it would be: will we be able to easily 
reason about such "reversed" view of series once mixed with "normal" 
series in the middle of our code or would it confuse many people?


Anyway, I think this one should be in the short-list of the possible 
solutions.

Andreas: your gist example nicely shows the continuous vs discontinuous 
numbering. I won't dispute   that continuity is better than discontinuity, 
but the more I think about it, the more I am convinced that the R2 
trade-off is "better" (in the sense that it is more easily understandable 
by users).

R2:
    >> values: [A B C]
    >> pick at values 2 -1
    == A
    >> pick at values 3 -2
    == A

R3:
    >> values: [A B C]
    >> pick at values 2 0
   == A
   >> pick at values 3 -1
   == A

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.

I'm pretty sure I prefere R2's behaviour. Also "pick 0" I could translate 
like "pick nothing" so returning none is fine in my mind. And I mostly 
use just R2 and I don't remember I had ever any problems with this.

R2's behaviour is only better in such toy situations without computed 
indices.

If those are deemed relevant, it might be actually better to capture 
the user's intent even more directly, than having them to abuse PICK.

I.e., you'd hardly ever actually write PICK series 1, you'd use FIRST 
instead.

We have FIRST, SECOND, THIRD to pick forward; but we have no dual 
set of functions to pick backwards. Therefore we fall back to crutches 
such as "PICK series -1".

Don't forget also path notation: `series/-1`.

We don't have convenient function names for picking backward because 
negative indexes are unnatural, as is "0th".

Path notation is somewhat rarely used with negative indices (and 
probably even rarer with computed components, which I think were 
only added as late as R2.6).

I did some investigation over the rebol.org library and a few other 
available R2 apps a while back, I think it's basically always /-1 
and /-2 for negative path indices.

0th is not that unnatural. I looked into an English dictionary yesterday, 
and actually found it defined as "the item before the first".

I use it often, there are 15 occurences of /-1 in Red codebase.

Yes, as I said: almost always /-1 and /-2.

I agree.

So even with just two convenience functions for those cases we'd 
probably cover the majority of uses.

(And could keep R3's behaviour for computed indices.)

Maybe, but we still have the 0 index issue, `series/0`giving you 
access to item before current series position is IMO highly confusing.

Not really.

I don't find it particularly confusing that 0 is the integer before 
1.

So quite obviously s/0 should give you the element in s that is before 
s/1.

I bet most readers here and R3 users will find it confusing. See 
my above `pick at values 2 0` example.

That's just because they are familiar with another equally confusing 
behaviour.

IMO, as long as we are in a 1-based system, s/0 will be confusing 
to most users.

Pekr, the reason it works for Python is because their series are 
always referenced from the start, so negative indices/offsets would 
otherwise have no meaning. REBOL has offset references to series, 
so negative indices/offsets already have a meaning for us.

s[0] is not confusing in C (even if newbies have sometimes issues 
with 0 itself), because C is 0-based.

Brian: except for the "learning new meaning" effort, do you see any 
other cons for having negative indexes work from tail?

The observation that we are using "a 1-based system" alone doesn't 
help you in any way with that.

I must have missed the proposal of BASIS?, but the fact that it would 
be a function or variable implies that it would be used to detect 
a global setting, like system/options/binary-base. Global settings 
like that have proven to be a universally bad idea in practice. Local 
settings are better.

In a pure 1-based system, you have neither 0 nor negative indices.

Agreed.

BrianH: BASIS? was proposed as the 0-based INDEX? dual.

Doc, it's not the "learning a new meaning", it's losing the meaning 
they already have. We need the meaning we have, we need to be able 
to reference offsets from before the current position.

Still the fact that `pick series 1` gives you the first item from 
current series position, makes the 0 position awkward.

Why?

0 is before 1, so pick 0 should give you the element before 1.

Actualy, as Ladislav repeatedly explained, having "pick -1" _not_ 
giving you the current element is just as awkward.

Andreas, oh good, whew. In R3 we're already having to replace all 
system options that affect MOLD with options to the MOLD function 
itself. It would be a shame to have to do the same for all of the 
indexing functions. Nonetheless, that meaning of BASIS? doesn't make 
sense for the name either, so I don't like it.

You can basically do:
- no 0 or negative indices at all

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

- disallow 0, have 1 return the current element forward, -1 the current 
element backward

- allow 0, have 1 return the next element forward, 0 return the element 
before that


All have their advantages and disadvantages. All require explaining 
and may not be obvious depending on what you expect.

Yes, but that's not how my brain see it by default, I need to make 
a conscious effort for that. Also, I might be tempted to then use 
0 to access the first item instead of 1...This is a pitfall where 
almost every new (and maybe some older too) will fall in.

Yes, but don't try to generalise from your brain to "most" or "new" 
users.

The only somewhat arguable generalisation is to "those who are well-used 
to R2's behaviour".

I know, but I must try to put myself in future Red users shoes to 
be able to make decisions.

I think for future Red users, R2's model is actually the worst choice.

If we do R2's behavior, make sure that PICKZ and POKEZ exist so I 
have something to use. They can call PICK and POKE internally. I 
need something that does computed indexes/offsets, and I can't afford 
to have a hole in the list (0 for R2), and I can't count on the port 
scheme supporting SKIP.

Just erroring out on index 0 is ann improvement.

Making "pick 1" and "pick -1" return the same element is an improvement.
R3's behaviour is an improvement.

R2's messy behaviour with a clean set of SKIP, PICKZ, POKEZ is an 
improvement.

If I'm not doing computed indices/offsets, or doing negative/0 offsets, 
or using using port scheme4s where PICK/POKE mean something different, 
then I don't use PICK/POKE at all.

and I can't afford to have a hole in the list

 Brian, could you give us some short code cases where this was a problem 
 for you? This would really help.

pick ser idx + off