World: r4wp

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.

(Seconded. If there is a link with Red, the link to Red is to prevent 
the same mistakes made again)

Brian, Maxim, the point of ALIAS is that it works with refinements. 
: : value assignments can't do that

The Chinese are going to take over the world, and they may well consider 
it an educational mistake to translate their Chinese R3 fork to English. 
To prevent having to learn Chinese, you could translate it back with 
ALIAS

The Chinese will have to take their world dominance from you first 
;)

They've already taken all my cousins in marriage...

Well, at least in tennis, currently the world dominance is here in 
Cz ;-)

Kaj, you can translate refinements using wrapper functions, and it's 
a better approach when you need to combine code from several nationalized 
sources. If you accept the idea of nationalized code, then you have 
to accept multi-nationalized code. This kind of thing is why I made 
sure R3 supported private modules.

That's an awful lot of wrapper functions, can't be done by a pure 
translator, and degrades performance

You'd still have to read Chinese to figure out what the code does

Right. As opposed to ALIAS, which can bring your system to a crashing 
halt, if you're lucky; if you're not lucky it will fail silently 
and stay a security hole.

With paren!, Fibonacci is now:

parameter: 40

fibonacci: func [n [integer!]] [
	either n < 2 [n] [(fibonacci n - 1) + fibonacci n - 2]
]

prin "Fibonacci "  prin parameter  prin ": "
print fibonacci parameter

To illustrate my point in a dumb way: alias 'true "false"

Yes, that's dumb enough that anyone would quickly figure out not 
to do that

Anyway, I increased the parameters of both Fibonacci and Mandelbrot 
to have a better benchmarking range for fast languages, such as Red/System

With this parameter and a more exact comparison, Red/System is 70 
times faster than Red

Red is 2.2 times faster than R3

Kaj, you are assuming that people don't want to create deliberate 
bugs. If any REBOL-like language with an interpreter of JIT becomes 
popular, we are going to have to assume that some developers will 
be malicious. Remember SQL-injection attacks. Don't add a feature 
that is only better than another way of doing that feature in that 
it is so trivially easy to use as an attack vector that anyone could 
use it with the stupidest code imaginable.

Programming is a security hole. If you want to allow people to do 
safe programming, you have to make it safe by disallowing many things. 
That would obviously include ALIAS

Also, REBOL-like languages are easy to generate from a dialect. A 
translator could write data files in a dialect, which could be used 
to generate the wrapper functions and assignment statements. And 
a half-way decent optimizer could get rid of the wrappers using the 
same methods that would allow it to statically resolve refinements. 
There's no reason to support an astoundly worse method.

I will happily allow people to use ALIAS on my Try REBOL server, 
just like I'm allowing most other REBOL features, because the server 
operating system is the party that establishes safe boundaries

astoundly -> astoundingly
Bad typing day.

You are welcome to try our server to see if you can break it with 
ALIAS

On my machine, REBOL catches up enormously when it can do many iterations 
in a very small loop. Apparently, a very small function will eventually 
fit in the CPU cache, so the VM gets less of a cache hit compared 
to compiled languages

With increased iterations, the effect is big in Fibonacci, but dramatic 
in Mandelbrot

Of course, most programs do not afford that advantage

I remember there being a spreadsheet expression evaluator that made 
it a point to have a small enough number of operations in its bytecode 
that it could fit two operations per byte. That means that with cache 
issues taken into account, its code was drastically faster than fully 
compiled code. The interpreter fit entirely in the instruction cache 
of a 486, and the bytecode was much smaller than regular native instructions, 
so the bytecode could be pushed into the CPU faster. This kind of 
a thing is even more of an issue now, with CPUs that are many times 
more faster than the memory busses, and even bigger caches.

On Mandelbrot with 50'000 iterations instead of the standard 1000, 
Red/System is 80 times faster than R3

R3 is obviously not designed with that kind of interpreter though, 
and isn't even bytecode compiled. That is more a trick for rebcode 
:)

GPU shader languages often use that trick though.

If anyone wants to help Red and thinks he can't start programming 
yet, please give it a presence here under Tested on RPi:

http://elinux.org/RPi_Programming

I have to wait to start programming my Raspberry Pi until I actually 
get it from Sinterklaas. After that I can try to test Red on it. 
I watched your presentation on programming in Red on the Raspberry 
Pi. No Syllable yet? WHat Linux did you use on the Rasp again Kaj?

Ah, so you volunteer for editing the wiki :-)

I said it in the video: Raspian, Arch Linux, and my preferred Bodhi 
Linux (based on Raspian)

Raspbian, that is