World: r4wp

BREAK is on my todo list. I might add CONTINUE too. GOTO could be 
useful for implementing fast FSM, but having some specific feature 
for FSM support would probably be a cleaner option than GOTO.


I personally very rarely need BREAK/CONTINUE, their usage depends 
on your programming style and the way you implement algorithms.

There are many way in which break and continue are being used amongst 
the different programming languages, most notable in case or switch 
statements.

BREAK in CASE/SWITCH statement is IMHO a very bad design choice leading 
to countless bugs. I'm glad Red and REBOL are doing it the right 
way.

Xmas feature teaser: http://t.co/jTYwNzfb

Implementing that feature revealed a few deep bugs in the current 
Red runtime code, I hope to be able to finish fixing them by tonight.

great stuff :-)

Console support! I'm waiting for it impatiently!!

BREAK/CONTINUE: I had to use those a few times in REBOL, it would 
be nice to have CONTINUE in Red too.

Awesome Doc!  Didn't expect to see a console so early.

It's a full REPL, so it's an interpreter + console. I was thinking 
about adding an interpreter since this summer in order to fill the 
gaps until the JIT-compiler will be there. Even when Red will gain 
JIT-compilation ability, for dynamic code with no loops, interpreting 
the code will be faster. Also, on some platforms, JIT-compilation 
is not allowed, so the interpreter will be handy to workaround those 
limitations.

Now, you have a better picture about the "full-stack" approach of 
Red language. :-)

The console is currently just a Red script, once we get devices and 
ports, it will be replaced by a proper console:// port.

This will make it much easier for everyone to pick it up and experiment 
quickly and easily.

It still misses a lot of features, but I think it could be fairly 
complete (on par with Red compiler) in early January.

I guess all this means we have to think a bit more about how to benchmark 
things rather than simply profile code pieces directly in the console?

Right, if you bench from the console, currently, you're just measuring 
the speed of the interpreter. When the JIT will be there, loops from 
the console might get JIT-compiled, so it will be even less relevant 
to bench from the console. My plan since the beginning is to add 
a profiler to Red, so you'll be able to make precise comparisons 
whatever way the code is run.

Great progress Nenad.

oh man, console, wooo hooo :-)

so, what does it mean, in R/S and Red scenario, that console code 
is "interpreted"?

Yes REBOL and Red do case/switch right way agreed!

Great progress Nenad on this console. 
It must be getting more and more fun to use Red now!!

Is the intepreter written in Red/System, or in Rebol?

(Red/System or Red.)

Red/System

so, what does it mean, in R/S and Red scenario, that console code 
is 
interpreted"?"


Currently yes, when the JIT will be there, we'll be able to JIT all 
console inputs or some of them only (depending if it is worth the 
trouble of compiling simple expressions).

The ability of Syntax-highlight will make Red console very attractive.

Jerry: might be fun having lot of colors in the console. ;-)

It just take 4 months to make the Red codebase double. ( 35K LOC 
=> 70K LOC)  Doc is very productive.

Peter contributed significantly also in this increase, but adding 
most of the unit tests.

REPL: very cool :-)

BREAK/GOTO/FSM: I also try to avoid BREAK, although it can come in 
handy. GOTO would make my 6502 emulator faster, but it's ugly. Having 
FSM support would be brilliant

FSM implementations are the only place I have ever used GOTO in C.

Me too

Oh wow, REPL is an interpreter. My jaw is on the floor :-)

Red just became even harder to explain to the world, though. :-) 
Perhaps we should refrain from mentioning any implementation details

Interpreter: that's the only way to make a REPL currently until JIT-compiler 
is there. I have thought about an alternative way using REBOL for 
the REPL and compiling the code in memory, then running it, but it 
would be a clunky solution (among other issues, would require an 
external DLL for being able to run native code from REBOL).

I can feel models of complexity collapsing in my brain. It just dawned 
on me that this interpreter will run on all Red platforms, not just 
the ones where REBOL runs, right?

Right, the interpreter will be part of Red's runtime library, so 
it will run on all platforms Red supports.

I'm so overjoyed right now :-)

The interpreter will unlock a lot of features that would have needed 
to wait for the JIT-compiler, like DO/REDUCE/COMPOSE natives. These 
natives can be statically compiled as long as you pass a literal 
block to them, but anything else needs dynamic execution. I was refraining 
from adding them to Red compiler so far, because  they could work 
only partially. Now, I can implement them fully, thanks to the interpreter 
acting as a fallback.

I'm so overjoyed right now
 Being overjoyed is the point of Xmas, isn't it? ;-)

Wow Doc! Congratulations on getting to this stage. What a great way 
to end the year.

Thanks Gregg. We'll do better for next year. ;-)

for those uneducated - what is the main difference between the rebol 
interpreter, and the red one?

in otjer words - how much is red compiled different to red interprete, 
speed wise?

Right Doc, thank you so much! I felt shivers going through my spine. 
I admit I also have Natasja on the couch, a cat on my lap, pears 
on the stove and John Lennon's Xmas song on the radio :-)

Once the Red interpreter + runtime library will be completed, none 
(modulo the REBOL semantics that Red will change or will not implement, 
which should be very minor).

Kaj: that's a good way to enjoy Xmas!

well, still not clear, what does interpreter do. So it takes a Red 
code, compiles it, and runs it? That would be JIT, no?

Kaj, ssems like a relaxed evening :-)

Exactly, but JIT can't be implemented until the self-hosted stage 
is reached, so in the meantime, Red will use that interpreter as 
a fallback.