World: r4wp

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.

and using something like /external instead of /global , meaning that 
the specified word is somewhere in parents context ?

It doesn't scale well, and as you can see in the following example, 
it can quickly get nasty:


    [/external obj1 [a b] /external obj2 [c d] /external obj3 [e f] /global 
    g h]

thanks for explanation. Having vars locally by default is one of 
the few nice aspect  of php. But as you said, in objects methods 
probably this leads verbosity.

You can't arbitrary pick a feature in one language and drop it in 
another one and expect it to have the same benefits...especially 
when they are so different. ;-)

That design note would make a great doc entry somewhere. Is there 
a Red wiki where we can stash these things, or what would be the 
preferred method at this point?

Davide, FUNCT in R3 declares all set-words in the code block as local 
by default. The commit comment says that Red's FUNCTION will act 
like that.

Doc, will FUNCTION have some of the other options that FUNCT has? 
(Feel free to adopt the FUNCT code: I wrote it.)

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

just a note: there is absolutely no need to support the end! datatype. 
REBOL doesn't support it either, in fact.

Jerry, I am not sure, I would post such a list, especially to Red 
FB channel. It looks almost discouraging. How will you measure the 
quality of Red e.g. running on ARM, and R3 not?

Moreover - Red is not a clone of R3, some things might be done quite 
differently in the end imo ....

Jerry: command!, end!, frame! and rebcode! are very unlikely to be 
adopted in Red. Also following will probably not be part of Red too 
(or not in a near future): event!, gob!, handle!. Meaning of decimal! 
will most probably be changed, float! or real! will be used instead. 
Money! will receive a different treatment than in REBOL (number of 
digits after comma will probably be adjustable).


Also, expect the return of hash! in Red, and new datatypes that do 
not exists in REBOL.

As you can see, it is not a 1-1 matching between Red and R3.

Routine! will also probably be back in Red.