World: r4wp

Excellent. With such a simple solution, even ordinal! seems excessive

Doc, I can splint a broken leg but it doesn't make it less broken. 
Still, you're lucky thet you haven't been caught by this.


As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work. If PICKZ and POKEZ are available, those of us who need something 
that works will have something. I don't mind even making R3 work 
like this, but only with the error and the alternate working functions. 
Let the people who insist on using path notation bear the brunt of 
the problem, so be it.

Same with x/0.

Of course path notation should still work on maps and other things 
where it means SELECT, not PICK,

Great discussion on this. I'll just say that "s/-1st" doesn't read 
well to me.

Yeah, s/-1 is better.

for pure arithmetic efficiency, as you've showed

 - actually, it is not for "pure arithmetic efficiency", it is for 
 users to be able to "naturally" work with it! Even Carl is unable 
 to use it without errors when it is too contrived, which demonstrates 
 that efficiency is not everything to consider.

Brian showed that R2 is not 

broken" as the head-index? function can be written." - Carl demonstrated 
(on his own bug) that it *is* broken, and what is broken is not "R2", 
what is broken is the index arithmetic, as Brian's example clearly 
demonstrates (you need to use CASE, index arithmetic cannot be used).

According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases.

 - as opposed to that, my opinion is that the HEAD-INDEX? function 
 represent an, "extremely simple" use case that everyone should be 
 able to solve without having a specialized training to be able to 
 do so.

Instead of throwing error on pick 0, can I propose adding undefined! 
datatype? In ActionScript, which I use quite often last days you 
can distinguish not defined and null values like:
	var a:Array = new Array();
	a[1] = 1;
	a[2] = null;
	log(a[1], a[2], a[3]); //<-- would output: 1, null, undefined

Btw.. I think it was me who asked Carl to implement path notations 
with parens allowing to write b/(n) It's in REBOL since 2.6.. sorry 
if it's causing confusion.
http://www.rebol.com/docs/changes-2-6.html#section-8

For example, when traversing two series at the same time while using 
just one index variable (which is pretty common), you need to be 
able to use the variable to correctly point to the corresponding 
places in both series, which logically *needs* some version of "index 
arithmetic".

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

 - however, this does not do what was requested, the number obtained 
 does not have the required property!

Oldes, undefined! is unset! in REBOL. I like the option to use parens 
in paths, so no harm done :-)

(what is interesting is the fact that when you rely on this, you 
get "kicked in the butt" like Carl was)

Probe with unset! is, that one cannot work with that in the most 
cases.. it would just move the error somewhere else.

(problem.. like:
>> f: does [] probe f
** Script Error: probe is missing its value argument
** Near: probe f)

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

Excellent. With such a simple solution, even ordinal! seems excessive

 - OK, since Kaj named the solution "simple", I can agree that (and 
 never questioned) that SKIP SERIES I is a good operation to use and 
 that really produces the simplest possible:

(PICKZ SERIES I) ?= (PICKZ SKIP SERIES I 0)

Otherwise, the whole nonsense of "ordinal datatype" just buries the 
whole thing under another pile of excessively complicated crap

Still, you're lucky thet you haven't been caught by this.
 - actually, he has been, just above he wrote:

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

, which caught him completely

(it proved he has no idea)

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work.

 - if PICK SERIES 0 yielding NONE is stupid, then triggering an error 
 is not less stupid

I should have said that it is not significantly less stupid.

In no way it is simple, for sure.

...and I still dislike the "PICKZ" name, although I am able to live 
with it...

So the correct version of Doc's solution is even shorter:

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

The only value for which this is not equivalent is 0, but that's 
an invalid index, anyway

Now we see why AT is designed with a discontinuity: to compensate 
for the discontinuity in indexes

To insist that AT should be mathematically correct, leads to indexing 
being broken

It seems prudent to me to explain this essential function of AT in 
its documentation

So the correct version of Doc's solution is even shorter:

head-index?: 
func [s [series!] i [integer!]] [index? at s i]
 - wrong again

Can you give an example?

aha, you wrote it as well, "The only value for which this is not 
equivalent is 0"

Yes, so outside the range of validity of the function

If s/0 would return error! in the new proposal, I think it would 
be doable to make AT equivalent to indexing by making the 0 argument 
return error!

You may create invalid solutions and declare them "valid inside...", 
yes, of course. In that sense any solution is valid.

It can easily be extended to satisfy your assignment, but why add 
the extra code if it's outside the usage range?

I disagree that "any solution" would satisfy the requirements

...outside the range of validity of the function

 if you mean the AT function, then it actually is "inside the range, 
 so you get bitten in the ass, eventually, as Brian noted

Hence my enhancement proposal

Well, I wonder, if the debate can have any resolution at all? What 
would be probably good would be if each person (who feels skilled 
enough to provide a solution), would define complete solution to 
the problem in REBOL-like languages ....

As far as I'm concerned now, just fix AT 0

(what is interesting is the fact that when you rely on this, you 
get 
kicked in the butt" like Carl was)"


I respectfully disagree. :-) You are right in that my proposition 
doesn't exactly match the requirements, because the requirements 
imply a 0-based reference that I've missed. So, here's a corrected 
version that matches your requirements:


    head-index?: func [s [series!] i [integer!]][(index? skip s i) - 
    1]


I am probably too influenced by the way Carl designed R2, but I still 
think that a 1-based index system has value. (Let's save the 0-based 
vs 1-based debate for another day)

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work


I agree that R2 not returning an error on 0 is a real issue that 
needs to be fixed. If someone thinks that disallowing 0 in a 1-based 
system makes me stupid, so be it.

If PICKZ and POKEZ are available, those of us who need something 
that works will have something...


:-) I think that at this point of the discussion, I can consider 
adding them to Red. (I'm fine with those names, but other will probably 
argue for different ones or refinement should be used instead, so 
let's leave such debate for another day. ;-))

Done. So what's next for Red? Functions almost ready, objects in 
the pipeline? :-)

Another incorrect version:


head-index?: func [s [series!] i [integer!]][(index? skip s i) - 
1]

Functions are almost there, I have some extra work to do for local 
context support and local variable binding before pushing the new 
code online.

You are right in that my proposition doesn't exactly match the requirements, 
because the requirements imply a 0-based reference that I've missed.
 - exactly the opposite is true, no "the requirements imply..."