World: r4wp

yes, they do, but - have you ever used them? :-)

I have used FOURTH once or twice, a long time ago, never used others 
above that.

(should be FIFTH, sorry for the typo)

Pekr, no, but they should still be available, if any scripts use 
them. The cost of adding them should be very small.

Have you ever seen source code that use such accessor above FIFTH?

I won't add them if nobody uses them, no matter the light cost.

I would certainly wonder why you stop at FIFTH.

SIXTH is used in some of the REBOL/Services source, written by Carl.

And his way of using it might be a good argument for continuing up 
to NINTH.

Example:


; Packet header values (keep in-sync with load-header and mold-packet):
ph-version?: :second
ph-session?: :third
ph-encode?:  :fourth
ph-req-len?: :fifth
ph-pay-len?: :sixth

TENTH is there too.

Now that you mention it, I remember seeing that code. Such code won't 
compile until we get JIT-compilation.

I would certainly wonder why you stop at FIFTH.

Why stop at TENTH? :-)

Any occurrence of above FIFTH usage in other than Carl's code?

We have 10 fingers.

If you count toes too, that makes it 20. :-)

I'm serious. I think his idea was that real beginners should have 
a good idea on picking values from code.

It doesn't make much sense to me to add features that nobody will 
use, just because we can add it, doesn't mean we should. For beginners, 
if they can't get a good picture on picking values with accessor 
up to FIFTH, I can hardly think that adding more will be of any help. 


The only reason for having them is the above code pattern used by 
Carl, but it can't be used for now in Red. Also, users are free to 
add more accessors names in their own code if they feel the need 
for it.

I've used FIRST, SECOND, THIRD, LAST and PICK for all the rest. It 
is even difficult to remember the name of the others as English is 
not my native language.

Actually REBOL had only up till FIFTH below Core 2.5. After 2.5, 
SIXTH through TENTH were added. Here's why:

http://www.rebol.com/docs/changes-2-5.html#section-21

Right, upper ordinal names were added in 2.6:

http://www.rebol.com/docs/changes-2-6.html#section-17

that nobody will use

 - I don't buy that, since I only just now realized this is a good 
 way to produce certain types of more readable code. This means I 
 might start using SIXTH through TENTH more often.

(one can learn a lot by reading Carl's code)

I could use ordinals all the way to TENTH. It is a common practice 
in advanced REBOL code to assign these ordinals to other words that 
are used as local accessor functions for series-based data structures. 
Using those accessor functions makes the intent of the code written 
with them much easier to understand. This is a trick that Carl and 
I use pretty often, and the reason he defined ordinals that high 
ion the first place even if only the earlier ones tend to be used 
directly.

Ah right, Henrik already posted an article with the reasoning. Good 
to know when they were added, it will help with R2/Forward.

Why stop at tenth?
 :) 

agreed hundreth seems more appropriate, let alone spelling of all 
of them 
Own aiiases can be added or not?

This bring up the case that Kaj likes 'length-of' like names. These 
could also be supported aliases as I see it, right?

If by "aliases" you mean multiple words with the same values assigned 
to them, or something like C-style typedefs, then yes. If by "aliases" 
you mean the multiple-spelling words generated by R2's ALIAS function, 
then please no. R2-style aliases that aren't limited to spelling 
differences that only differ in character casing have proven to be 
a bad idea.

I have my Raspberry Pi now (And an Arduino uno board too). Only have 
to wait until I get it from Sinterklaas now before I can play with 
them.

I mean that two words mean the same function. Like Erste: :first

is that a bad thing?

I have bad experiences with Value and vaLue not being/referencing 
the same thing.

It can be hard enough to tell global and local variables with the 
same name apart.

Like Erste: :first

 "is that a bad thing?" - BrianH tried hardly to explain he did not 
 mean that, and he succeeded, at least for me

I have bad experiences with Value and vaLue not being/referencing 
the same thing.

 - that is where aliases ("automatic", casing aliases) are used in 
 REBOL, so you do not have to be afraid of such problems

I was not completely sure Ladislav. The 'multiple spelling words 
generated by R2's ALIAS function' part I do not understand.

Right. Casing R2-style aliases are OK, and that is how case-insensitive 
words are implemented in R3 (and in R2?). Aliases which differ of 
something other than case cause major problems, corrupting object 
access when the other spelling already exists as a separate word 
in the same context, as happens automatically in R3 when the word 
is loaded in the user script  to be passed to the ALIAS function 
as a parameter. That's why there's a ticket to remove the externally 
visible ALIAS function from R3.


Just assigning the same value to another word, as Arnold suggests, 
is OK (and is what some other languages mean when they talk about 
"aliasing" so I understand your confusion).

I read the docs http://www.rebol.com/docs/words/walias.htmland as 
I understand it stampa: :print differs from alias 'print stampa 

because the latter does this in a way where ALL occurences of stampa 
even in different contexts are 'replaced' whereas the first form 
only applies to the current or global context not interfering with 
local usage.
Is that about it?

Actually not, the difference is even deeper. Like this:

alias 'xxx "yyy"
xxx: 1
yyy ; == 1
yyy: 2
xxx ; == 2

also,

equal? 'xxx 'yyy ; == true

Almost. It doesn't "replace" the word in all contexts, it registers 
another spelling for the word in the place where word symbols are 
stored, then when you refer to the word with either spelling it will 
point to the *same* word.
However, if you write code like this: alias 'print 'stampa

then that code, just by being loaded, creates two words in the user 
context with those two spellings. So when the ALIAS function links 
the two spellings then there is a conflict in the user context, where 
"stampa" refers to both the word 'stampa and is an alias for the 
word 'print and at runtime you can't really tell which word you mean. 
If the system resolves this conflict by resolving to the alias then 
you have overriden the original word, which makes ALIAS a security 
exploit. If it resolves to the original word then ALIAS simply doesn't 
work. Either way, the function needs to go away ASAP.

Plus, what Ladislav said.

I see the bad side. Alias shoul dnot have that big an impact unless 
an alias was designed on purpose into the language. For instance 
a support a complete spanish/chinese version for educational purposes?

That was the intended use, but it did not take off, as it looks. 
Virtually nobody uses the ALIAS function.

I would if it will be implemented in Red. I've been forced to use 
the lowest common denominator of REBOL features for many years to 
be able to port code between versions and clones

Arnold, you can support a complete chinese or spanish version of 
R3 using a module and those worda: :wordb value assignements, no 
ALIAS required. But it would be a mistake to do that for educational 
purposes, because it would get in the way of them learning regular 
Rebol/Red code. You might want to do that for non-educational reasons 
though.

Re: FIFTH+, It should be easy to provide a REBOL compatibility library 
for things that aren't seen as essential for Red.

Certainly! Modules make the monolithic model not as useful. We even 
intended to switch to more of a modular model for R3 - that's the 
whole reason modules were added.

aliases can be used with refinements which is a bit weird 

>> alias 'any "xxxxxxx"
>> get/xxxxxxx 'red
== 255.0.0

who is going to drop ALIAS from R3-open-sourced?

I hope that it will be one of the first things done. The internal 
aliasing functionality is fine and should be still supported, but 
it should be locked down so it won't be possible to make an external 
ALIAS function. It even existing is a major problem.

(Sorry Doc about the off-topic stuff) And open-source forks that 
try to alter R3 to make ALIAS possible again will thus be that much 
less stable ond secure, so it will be an argument against their use. 
ALIAS is hostile to the R3 system model, and everything it might 
be a good idea to use ALIAS to do in R2 can be better done with other 
methods in R3.