World: r4wp

Yes, rather different model

Jerry: it's a bit premature, but yes, that should be the way to create 
and consume redbin data. You can also add SAVE to that list.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Personally, I feel that Google's V8 & Apple's Nitro give orders of 
magnitude speed improvements over early JavaScript Compilers.

Peter - in the case of JS engines - is that only about the compilers, 
or also about an overal architecture change?

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.

Will also "self-hosting" - rewrite of Red/System in Red, help too 
in that regard? Or is that unrelated?

Not really on the run-time performance, it will boost compilation 
time only. The main motivation for being self-host is the JIT-compiler 
(we need to embed the target compiler in Red runtime).

Today's new features:

- FIRST, SECOND, THIRD, FOURTH, FIRTH and LAST functions added.
- Paren! datatype added.
- Compilation of parens expressions now supported.

You should now feel a bit more "at home" with Red. ;-)

SIXTH, SEVENTH, EIGHTH and NINTH also exist in REBOL. :-)

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.