World: r4wp

...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..."

I agree that R2 not returning an error on 0 is a real issue that 
needs to be fixed.

 - if you want, you can trigger an error, but I don't think it makes 
 any sense to "return an error".

I guess I will just spend the rest of the day doing something useful, 
like coding, instead of having to play mind games with you. ;-)

Ladislav, I didn't say triggering an error wasn't stupid, I said 
that it was less stupid because it was louder. R2's current behavior 
is made worse by it happening silently, making it difficult to track 
down where you code went wrong when it called PICK or POKE with 0 
by accident. Triggering an error makes it easier to find these situations. 
It's a way to ameliorate a bad situation.

Doc, refinements slow down functions unless the optimizer can resolve 
them staticly. If compatibility is a value, it's worth mentioning 
that REBOL doesn't have such an optimizer, so it is stuck with the 
same situation that you have when you can't know whether the refinement 
will be used ot not (see APPLY). Separate functions are better in 
this case.

I am probably too influenced by the way Carl designed R2

Funny, I am probably too influenced by Carl's assessment of R2 after 
using it for years and thus having realized that certain of its design 
decisions were actually mistakes that need correcting.

Ladislav, don't quibble about "return" vs. "trigger"; you don't know 
yet how errors will be implemented in Red. In R3, for instance, errors 
are triggered by being returned internally. Try to keep the arguments 
on topic :)

Ladislav, I didn't say triggering an error wasn't stupid, I said 
that it was less stupid because it was louder.
 - yes, that is correct, I do agree with you

Re "influenced by Carl" - I think that it is good to strive for simplicity, 
however, indexing is not simple when index arithmetic does not work

And, yes, Henrik's solution using AT could be considered a 1d) solution 
for Red in case the functions will work as he indicated

BTW, 0 is the reason why many arithmetic algorithms work, so getting 
rid of 0 helps only to get back in time before 0 was invented, to 
the time when those algorithms did not exist. (the word algorithm 
itself is actually pointing to the city where a zero proponent and 
matmenatical giant Muhammad ibn Musa lived).

FYI, it means at least 1282 years back in time, but, actually, much 
more, taking into account that even before some nations used 0 successfully.

'Ladislav, don't quibble about "return" vs. "trigger"; you don't 
know yet how errors will be implemented in Red.' - I wrote that in 
hope there will be some reasonable compatibility with REBOL, but, 
you are right, that I should not...

All that matters is how it appears to work from the outside, not 
how it works internally :)

However, in REBOL (no matter how it is implemented) there is a difference 
between "returning an error" and "triggering an error". A compatible 
implementation would need to maintain such difference, I guess.

This does not have anything in common with "how it works internally".

While it's too late to keep all this chat out of the Red channel, 
if you would all like to continue this very specific discussion, 
I will create a group just for that.

Thanks, Gregg

Preliminary support for Red functions (please read the commit log)::


https://github.com/dockimbel/Red/commit/cc5c8dcb839572bb25559f964ed7d30419cb5a31

That's great Doc!

There's an entry missing in the commit log:
- dynamic function creation is not yet supported.

Cool, now it's a real programming language

I like the plan for FUNCTION

This is a great new Doc ! BTW why  use /local refinement ? Don't 
you think that would be better to have words local by default, and 
to use /global when needed ?

Such model would not work with lexical scoping. For example, you 
wouldn't be able to access words from parent object from a function 
because you will be only able to define local (to function context) 
or global context words.