World: r3wp

And /local is special, not just another refinement?

Yes, it's a reserved keyword. I planned to add refinement support 
also, but I'm not sure I will need it to implement Red runtime, so 
it will be probably postponed.

how many attended the conference?

We were 5, but it felt like 10 ;-)

heh, well having actually had a conf i think you can use a 3x multiplier

Brian: here's an example of /LOCAL usage from my Red/System tests 
scripts (just a variation on the real PRINT function):


print: func [s [string!] return: [integer!] /local lf [string!] sz 
[integer!]][
	lf: "^/"
	prin s
	sz: 1
	WriteConsole stdout lf sz written 0
]

No tmp variables then :)

Nope.

Cool examples, Doc

The real PRINT is defined as: 

print: func [s [string!]][
	prin s
	prin "^/"
]

Only string!, no binary!?

I'm wondering about the Unicode strategy...

In Red/System, I mean. Of course Red will have both.

Binary! is half-supported. It was part of my initial list of type 
to support, but as I didn't needed it so far, it's not supported. 
That might change when I'll implement the lexical analyzer.

Have you decided yet whether the lexical analyzer will have the same 
source-is-UTF8-binary strategy as R3?

I plan to support UTF-8 scripts for both Red & Red/System. The memory 
storage model is not yet decided, could be UTF-8 or UCS-2.

And arguments and locals can only have one type in their typespecs 
for Red/System?

In fact, they can have several types as long as they take the same 
space in memory, but support for that has not yet been implemented.

Do you currently compile the above directly to binary machine code?

Yes, machine code, then generating an executable.

ABI differences will probably give you the heebie-jeebies :)

The whole compiler is 40KB, the linker is 20KB.

I did the PE/COFF support, no other ABI can be so screwed up. :-)

Obviously, GCC is superior at 50 MB or so

That is only the binary format :)

I assume you currently do x86 stdcall only?

Yes, but the support for cdecl is like adding a couple of lines to 
the current code.

Sure. But that quickly gets extremely annoying :)

Red/System uses stdcall for its own functions, I found out that it 
was generating shorter code than cdecl.

That's why stdcall was invented :)

Or on x86, fastcall, rather :)

The really annoying part was having to reverse the arguments list 
to support stdcall. It's a much more difficult when you're compiling 
in one pass directly to machine code.

Fastcall, sure, that would be the target in a future version with 
an optimizing compiler.

Do string references in Red/System have indexes, or are they just 
pointers?

They support indexed read/write accesses like in C, but using a REBOL 
syntax, so s/1, s/2, s/3...

I meant offset references an internal pointer to the head and an 
offset index, like s: next s.

Indexing with a variable should also be possible: 
s: "hello"
c: 1

s/c or s/:c (haven't decided yet which one is the more appropriate)

Nope, no indexes like in REBOL strings, that's too high-level for 
Red/System.

Going with the latter (s/:c) would be more compatible with REBOL 
and Red, and leave room for expanding Red/System's capabilities in 
the future.

No offset references means no set-word syntax in FOREACH - good to 
know.

Agreed

And no FORALL and FORSKIP.

Perhaps, that's what I'm thinking too, but s/c looks more consistent 
with current Red/System abstraction level.

I might add support for FOREACH for string! & binary! if this can 
make me avoid to add FOR. :-)

Things would be less confusing if Red/System and Red were compatible 
for corresponding concepts. This would also let you prototype Red/System 
code in Red.

You would still need something like FOR if you don't have offset 
references, because FOREACH doesn't let you modify its argument without 
set-word syntax.

Well, I already have WHILE, so FOR is optional anyway, just syntactic 
sugar. I should add REPEAT too, if I still miss FOR after that, I'll 
add it.

Enough for tonight, it's very late here. I just wanted to give you 
some taste of what Red/System would look like. I'll work on Cheyenne 
new release and new documentation tomorrow, I should be able to get 
back to Red after that. I hope to be able to put the current codebase 
on github during the weekend.

Good night!

Thanks!