World: r4wp

From R3-alpha world:

Carl:	It is zero based for math computation reasons. If you think 
that is wrong, we should discuss it and correct it soon.	11-Oct-2007 
6:03:15 PM

Carl:	Rest of REBOL is one based for this reason: first = pick series 
1	11-Oct-2007 6:03:33 PM

Carl:	The solution we discussed, but have not yet implemented (but 
it is easy to do) is to add a PICKZ (or PICK0) function.	11-Oct-2007 
6:05:41 PM

BrianH	: Those math computation reasons are why I prefer zero based. 
I tend to use SKIP instead of AT for the same reason.	11-Oct-2007 
6:06:09 PM

BrianH	: Please add PICKZ and POKEZ - I liked them in rebcode.	11-Oct-2007 
6:06:46 PM

If PICK-FORWARD 1 returns the current value, PICK-BACKWARD 1 should 
of course also return the current value.
 - which, actually, leads to "overlaying", not to "gap-making".

(Carl in the post above was answering why vector in the initial R3 
version was 0-based. He changed it afterwords to 1-based but never 
created promised *z functions.)

Frankly, I am not overly enthusiastic about the PICKZ name, any other 
reasonable idea?

(I mean of the name for such function)

I don't think there will be better. And it was used in rebcode.

In the synonyms for PICK I found ELECT, what about that?

REPICK REVPICK PREVGET NEGINDX PREPICK PICK-PREV NINDEX 
ELECT? -> NEGLECT ;)

My idea:

One-based        Zero-based
AT                        SKIP
PICK                    ELECT
INDEX?               BASIS?
FIRST                  ELECT0
SECOND            ELECT1
THIRD                 ELECT2
FOURTH             ELECT3
FIFTH                   ELECT4
SIXTH                   ELECT5
SEVENTH            ELECT6
EIGHTH                ELECT7
NINTH                   ELECT8
TENTH                  ELECT9
LAST                      LAST
HEAD?                  HEAD?
TAIL?                     TAIL?
LAST?                    LAST?

Having that, I would just be able to foget about one-based indexing 
happily ever after...

maybe adding ELECT-1 that may be needed often as well.

I would hardly ever use elect* actions as I almost never use first, 
second... actions. Actually my english is so bad that I see elect 
for the fist time:)

I am in favour of ELECT also because it looks "higher level" than 
PICK. PICK seems to look quite "Low level", while in REBOL it isn't 
as "Low level" as it may suggest at the first sight.

(I mean to the users coming from other languages)

as far as I am concerned I would not need ELECT3 and above, but up 
to ELECT2 they look nice to have.

Ah.. elect like election... that makes sense to have it zero based 
as usually it's hard to elect someone from possible given choices... 
sorry off topic.

LOL

aha, still not done, I would need to find a name for the zero-based 
counterpart of POKE...

elect is very like select

I had this idea when under the shower, so it is still a bit wet: 
DOWNPICK

Counter part DOWNPOKE and you only need to steggle (twist) idf it 
should be downpick 1 or downpick -1 ;)

the problem with DOWNPICK, REPICK, and some others is that they aren't 
related to the purpose of the function in any explainable way

PICKZ's problem (in my eyes) is only that it actually violates REBOL 
naming conventions.

POKE counterpart names: seems that some of PUT, DEPOSIT, INJECT may 
be chosen

Ladislav: are you advocating for having two conventions, both 1-based 
and 0-based?

Negative indexes applied from tail of series could be a good option, 
that would help replace the `back tail series` idiom.

Doc, ticket #613 is for the introduction of separate functions that 
do 0-based indexing. It's not related to 0-based indexing anywhere 
else.

Ladislav, REBOL doesn't have a naming convention that handles 0-based 
addressing. If you can come up with better names, hopefully just 
as short, go right ahead.

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.