World: r4wp

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

Aside from that, my opinions are documented.

Make sure that the names of PICKZ and POKEZ are immediately relatable 
to PICK and POKE, the way that FUNCTION, FUNC and FUNCT are related.

PICK0 or PICK-0 might do. Definitely not ELECT, since the kind of 
selection that is done in elections is not related to the type done 
when you "pick" something. In US English there is a colloquial term 
"pick out of a lineup", which relates to series in a way that noone 
would think of the term "elect" (unless they are convinced that all 
politicians are crooks). PICK and POKE are from Basic, old-school 
tech terms that are more closely related to assembly instructions 
than they are to any high-level operation.

You wouldn't need to implement PICKZ and POKEZ as actions. Just implement 
them as regular functions that call PICK and POKE, like the ordinal 
functions are in R3.

Not sure what you mean by "regular functions", but FIRST, SECOND, 
etc are native! in R3.

In Red, there isn't that much difference. But in R3, natives are 
more like regular functions than they are like actions or ops. The 
implementation language is different, but the dispatch model is very 
similar. On the other hand, the dispatch models for actions and ops 
are very different from regular natives.

A native is pretty much called directly, maybe a little argument 
marshalling but that's it. An action dispatches to a handler associated 
with the type of the first argument, one of a table of such handlers. 
The action itself doesn't do much - everything is done by the handler.

Adding more actions makes it more difficult to implement datatypes. 
That is why R3 has fewer actions than R2, why some former actions 
are now natives.

Ladislav, what about ADDRESS in place of ELECT?  Fan of DEPOSIT. 
 Umm, adding I actually prefer one based indexing and lean toward 
it.

BrianH: just curious - why don't you like negative indices starting 
from the tail of the series? Some ppl expressed here, that it is 
nice feature in Python. Do you see any negative consequences with 
such a design?

I don't care for ELECT, the word. As names, I would prefer FIRST-BACK, 
SECOND-BACK, etc. to ELECT, though I've only been skimming the discussion 
here.

It's been too long for me to remember the discuission for R3, but 
I think I ended up liking the *Z convention, because it's easy to 
understand. ELECT and BASIS? don't make immediate sense to me.

IMHO adding both zero and one-based selection will only confuse.

right - POKEZ and PICKZ are for nerds anyway, so - who cares about 
the names? :-)

jokes aside - I am not sure I like different names. Any name will 
NOT fit the purpose? At the first look, how should user know, that 
different name is there just to distinguish the zero vs one based 
indexing?

it will be just another concept to learn imo ...

TAIL position exists without pointing to any value

 - the way to imagine it is to think it as pointing to the END! value. 
 (this solves the mistery of what END! is in REBOL.) You can imagine 
 END! as being the same as the NUL character in a C string.

Re: python and negative indices... python does not have series positions, 
so they can afford doing that. a REBOL-like language simply can't. 
it's much simpler to just write "pick tail series -2" for eg.


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.

the most sane way to make a decision here is to come up with use 
cases, probably. then we can intuitively see what is wrong.

The problem with R2 can be easily seen with:

>> b: skip [1 2 3 4 5 6 7 8 9] 4
== [5 6 7 8 9]
>> for i -4 5 1 [print [i pick b i]]
-4 1
-3 2
-2 3
-1 4
0 none
1 5
2 6
3 7
4 8
5 9


Now, you could also say that you should never iterate over a series 
using indices. But, then why have PICK at all?

Reposting another illustration of the problem with R2 I posted earlier, 
as it fits:
https://gist.github.com/5af73d4ecf93ac94680a

I can tell you why I don't like the idea of continuing from the back 
of the series.

Most data is not in a cyclic group, it is finite so definitely at 
the beginning you do not expect it to continue from the tail.

And a PICK/BACK refinement is also not an option?

You do not necessarily have to iterate over the series. I look up 
some values in a table and retrieve or store data at that index of 
a series.

But than again I use subscripting b/(i) over 'pick, maybe I must 
go back to REBOL School  ;-)

the most sane way to make a decision here is to come up with use 
cases,


I can't agree more. What I am wondering is: have rebolers ever hit 
that specific issue (0 gap producing a calculation error) at least 
once? My feeling is that it is an extremely rare error case (but 
a nasty one) that could have been mitigated by just making PICK raise 
an error on 0.


Now, you could also say that you should never iterate over a series 
using indices. But, then why have PICK at all?


Right, IMHO, you shouldn't iterate over a series using indices, unless 
you have a good reason for it. In the general case, people should 
use "navigational" functions to walk through a series. PICK is ok 
as long as you don't PICK on 0.

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.