World: r4wp

Agreed, "not usable" is a little harse. Bad and awkward, but once 
you work around that it is usable.

harse -> harsh

I guess you're not talking about R2, which index arithmetic has proven 
to be very usable in last twelve years (at least) through countless 
*working* user apps.

 - "working" are only the ones limiting the index arihmetic to some 
 special cases. Those not limiting themselves to such cases are not 
 working.

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

... have to know* that you have to work around it ...

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

 - yes, "you have to work around it" is (for me) a different formulation 
 equivalent to "not working"

I am able to do any work-arounds necessary at any time. However, 
I prefer to use a working solution.

Knowing Carl's preferences, I did not insist on switching to 0-based 
indexing. However, for the sake of arithmetic, I at least convinced 
him to switch to "continuous indexing".

Here is a task I consider relevant:


1) define a function obtaining a series S and an index I and yielding 
an index J such that PICK S I would be equivalent to PICK HEAD S 
J
1a) do the task in R2
1b) do the task in R3
1c) do the task in R4 with zero-based indexing

This is my solution of 1c):

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

(that is what I call "working index arithmetic")

This is my solution of 1b):

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

(again, a case of "working index arithmetic")

(although a bit more complicated than the 1c case)

1a) is a task for people stating that "zero does not exist"

...and also for people stating that "index arithmetic *is* working 
in R2"

Note that the difference between 1c) and 1b) seems to demonstrate 
why 0-based indexing may be found more convenient than 1-based indexing

I know this would be consiidered a "workaround" but

head-index?: func [s i] [i - (index? head s) + (index? s)]

Testing your implementation with:

1 = index? head s
0 = i
2 = index? s

i get:

1 = head-index? s i

, which is incorrect

(your solution is actually 1b, not 1a)

It would work for 1c too.

yes

(but in any of those cases my solutions are simpler)

In REBOL, we have an important design rule to optimise for the common 
case. Your exercise is contrived, while R2 still optimises for the 
common cases

OK, for Kaj: I do not insist the solution has to be "optimized".

just working
 will be OK

Another case of the common case is that Red's intended common audience 
is common people, not mathematicians. While R3 "works" for mathematicians, 
R2 is the one that works for common people

So, if we consider Peter Wood a "common man"(no offense intended), 
do you state that his solution works?

I already stated I'm not talking about your mathematical exercise, 
but about common programming patterns in REBOL, such as series/-1

OK, so you feel offended that Peter considered my exercise worth 
trying?

Not at all

Kaj is write I wouldn't write such a function.

...but you did...?

To oblige you, because Peter is such a nice commoner :-)

I do not think he really felt obliged?

Also, optimization (as many programmers know) is not about making 
something incorrect or non-working. It is about making something 
better in some sense.

Yes, and that's what Andreas' formulation of the ordinal! proposal 
does

Well, I would state that my task looks like a "simple enough task 
to tackle", and the one even inexperienced users (surely not only 
mathematicians) should be able to tackle, and they would, as Peter 
demonstrated, if the index arithmetic weren't broken.

That's not the point; as Peter said, a common REBOL programmer wouldn't 
program this function exactly because there are better solutions

Give us a better solution than PICK/POKE then.

One note: as far as I can tell, s/-1 is not a common pattern at all, 
but rather a quite "uncommon" one in as far as it is rarely encountered 
in real REBOL code. FIRST and /1 are the common patterns, which are 
not touched by R3.


Actually, the only thing different in R3 that arguably "works for 
common people" in R2 is this uncommon pattern of s/-1 and s/-2. Every 
other use of negative indices is broken in R2 (and as such, works 
for neither mathematicians nor common people) but works in R3.

I really don't care about path syntax with computed indexes, it's 
ugly and awkward, and broken because of the 0 hole. I'd really rather 
use a function. As long as we get PICKZ/POKEZ, I'll be good. We already 
have SKIP to act as a non-broken AT. But at least plug the hole with 
a triggered error, so it won't mess people up silently. It's a huge 
failure, at least make not fail silently.

As Ladislav demonstrated, 0-based is better anyway for computed indexes, 
so PICKZ and POKEZ would be better to use even if PICK and POKE didn't 
have the hole

Nenad already counted a lot of occurrences of /-1 in Red. Most others 
have failed to contribute analyses of real code

14 occurrences of /-[1-9] in current Red sources, 1 is from makedoc2.

Which means that either Doc prefers path syntax over function syntax, 
or path syntax was implemented first, or both. Nonetheless, it's 
real code of any significant complexity, so it probably includes 
backward index use.

I just counted three occurrences in PowerMezz, and two occurrences 
of /-2

Most Red code is currently R2 code, so implementation order doesn't 
come into it

Just for comparison: Red's sources are 13k lines (including whitespace 
and comments) of code.

The preference then. So, at least 2 people like to use path syntax 
(PowerMezz was written by one guy). It was bound to happen that someone 
wouldn't find that syntax ugly :)