World: r4wp

Elapsed time for fib on Reds is 0, process time is 0.103 - so fib 
is hundreds of times faster on Reds compared to R2 - so I guess it 
depends on the program as to the speed difference

That's consistent with my laptop that I used for this month's recordings, 
about a factor hundred

It's impressive - Reds will open a whole new world for us C haters 
:)

Yep

What is really exciting is the concept of creating an OS which is 
completely red/red/system - the control, power and speed of that 
woulod be phenomenal

Red/System v2 will be faster, it will benefit from a lot of optimization 
stages that do not exist in the current version. I expect a raw speed 
improvement of between x2 and x4. Maybe more if we can use some SIMD 
to speed up some processing (but that will probably require new datatypes, 
and/or new looping functions).

Ken: full Red stack, yep, that's the long term goal. ;-)

Carl though about it (Lava/MagmaOS), we will make it real! ;-)

Yes - it could truly revolutionise computing - a single high level 
language which enables you to program everything - fantastic concept!

it used to be called  language  C   ;-)

Well, one day, Carl sees the light at the end of the tunnel, and 
joins Red ;-)

Doc - will we have something like Rebin?

I hope that a lot more Rebol coders get on-board with Red to help 
Doc and speed development - Red is the future I think, not interpreted 
Rebol, as brilliant as that has been in the past.

For me the difference is elsewhere - Red has a momentum, which Carl 
almost/mostly killed by the 18 months of information embargo. Red 
has a lead - DocKimbel, who is dedicated to the matter, whereas R3 
looses its main lead - Carl.

it would be nice to formalise, e.g. to have /bindings subdir, where 
partricular systems would be represented by subdirs, etc.


We already have some place for that since many months (it's the /library 
folder): https://github.com/dockimbel/Red/tree/master/red-system/library

Got my raspi board! :-) Any advice on the type of SD card that works 
the best with it?

Haven't got power for mine yet

SD card: a slow and not too big one :)

Have a look at http://elinux.org/RPi_VerifiedPeripherals#SD_cards

64GB SDXC Class 10 Extreme (45 MB/s UHS-I) (SDSDX-064G-X46) - works 
with 2012-07-15-wheezy-raspbian

:-)

SanDisk cards seems the most tested ones.

I think most SD problems are solved with recent boot loaders, anyway.

I have a few SanDisk Class 10 Extreme myself, which didn't work initially 
when I got my first RPi, but work just fine now.

http://uk.farnell.com/raspberry-pi-accessories#operatingsystem
has some more SD cards and accessories - as described in my new book 
: The Raspberry Pi - a quick start guide - by Maik Schmidt pubished 
by pragmatic programmers

Thanks Gerard!

Implemented IF and EITHER, I just wanted to share their implementation 
with you (extract from Red compiler source)::

	comp-if: does [
		comp-expression		
		emit compose [	
			if (logic-true?)
		]
		comp-sub-block
	]
	
	comp-either: does [
		comp-expression		
		emit compose [	
			either (logic-true?)
		]
		comp-sub-block
		comp-sub-block
	]

Shouldn't be more complex than that, no? ;-)

Turing is calling

forth computers are single stack .. they haven't conquered the world

Are you sure?

I wonder for some time why you give long c-like prefix names to every 
functions. 
Is the context not enough? like rebol style does prefer.
Or is that you fear to forget what's doing your own code ? ;-)
Or maybe there is a technical reason behind it I missed.

No offense intedended here Doc, just a genuine question about your 
prefered coding style.

I'm not sure what you mean by "long c-like prefix names to every 
functions."?

comp-*

You talk about the "comp-" prefixes I use in the compiler code?

yep

is the context not enough ? I mean you use a dffierent context when 
compiling.

Well I'm not sure if what I'm saying makes sense even for me, sorry 
;-)

I should go read some manga and relax

It adheres to REBOL convention for naming functions (starting with 
a verb) but it also serves other purposes:


- as a way to classify the compiler internal functions by category 
or compilation stages, e.g., comp-* functions do the translation 
+ code generation, fetch-* just fetch source code, check-* perform 
type or spec verifications, emit-* just generate target code, etc...


- as a way to stratify the code in compiler context. As I want to 
keep the compiler internal code in one piece (because of too many 
common dependencies). It helps me navigate quickly in the code when 
searching for a bug for example.

Ok I see your point with the depedencies, different contexts could 
be annoying.

They might do more harm than good.

(in this specific use case)

The model you're using to compile is nested functions which in the 
end emit code.

Don't you think several well separated stages which emit their own 
dialect would avoid to much depedencies in your code ?

Another benefit of stages is that you can easly add/remove specific 
phase like optimization ones

In return it would be slower

but more flexible

Good point and I totally agree with that. That's basically the plan 
for Red/System v2. But, as you say, it can become quickly very costly, 
so it needs to be done carefully (needs time) and *sparingly*.

yeah but you could have different path containing different stages 
to allow fast or slow compilation (with full optimization)

My goal with the bootstrapped current version was to try some experiments, 
as all the current REBOL code will be trashed at the rewrite in Red 
stage. I wanted to see how far I could get with very simple design, 
so I can test how REBOL features can help or get in the way for writing 
complete compilers.

Also, the implementation speed factor also weighed a lot in architectural 
choices for the bootstrap code.

I could have gone by the (Dragon) book and done it in classic way, 
but that would have been a shame IMHO, to not try new approaches 
with a language like REBOL.

I think the way you've approached it so far is great Doc, though 
I haven't said much.