World: r3wp

I figured as much, but thanks for the clarification.

ASSERT/type can do deep type checking of paths, and after the function 
returns the code can assume that the assertions are true. This can 
help with making code that would otherwise be too general for the 
inferencer to handle be really specific. To work best, ASSERT would 
also need to be built into the language, like the loop functions.

When ASSERT is compiled the statically determinable assertions can 
be dropped from the output code, leaving only the stuff that needs 
to be checked at runtime.

Building in the type test functions into the language would have 
the same effect. The type inferencer could determine some of them 
statically. If they are regular functions, that would require partial 
evaluation to get the same effect.

MikeL: LuaJIT is definitely the best model to follow for Red's JIT, 
at least performance-wise.


BrianH: thanks for the insightful explanation. This seems like a 
nice way to make the inferencer smarter. Is ASSERT used a lot in 
R3 mezz code so far?

Yes, for situations that the function type specs can't handle. It's 
mostly used for making code more bulletproof, but it can speed things 
up too. Even more so in Red since the runtime overhead could be eliminated 
when unnecessary.

My old version of LOAD used it a lot, but the new version uses the 
CASE/all style to get the same effect with less overhead.

See sys/make-module* for a good example of its use now.

ASSERT and ASSERT/type don't have a way to test the number and type 
compatibility of function arguments for first-class functions. It 
might be worth looking into a way to check that, perhaps as an extension 
of ASSERT, which could be ported to R3 as well. ASSERT is also high 
on the list of functions to backport to R2 as a native function.

Code like this in FIND-ALL:
    assert [series? orig: get series]

could be internally rewritten into this as part of the compilation 
process:
    orig: get series assert/type [orig series!]

You should definitely make sure that Red/System supports CASE and 
CASE/all, since the style that those functions allow leads to really 
efficient code.

I didn't need a CASE-like statement so far in Red/System, so it's 
there yet. Current implemented control flow statements: IF, EITHER, 
UNTIL, WHILE, ANY, ALL. So implementing CASE should be doable.

it's there
 => it's not there

Look at the source of LOAD and sys/load-header for some good examples 
of the CASE/all style. It's worth supporting.

I'm sure it would be nice to have it, but my short term goal with 
Red/System is to just code the minimal set of primitives required 
to build the upper layer (Red's runtime layer). I was hoping that 
other developers could keep expanding/improving Red/System while 
I would progress on the Red part.

Good point.

What makes CASE/all different from a long sequence of IFs?

(In respect to Red/System, where those will be equal, performance-wise.)

Maintainability of code. We found that the CASE/all style makes changes 
to code easy to make, and control flow easy to understand. This realization 
came out of the process of rewriting R3's module system into easier-to-maintain 
code.

It's sleep time here, but I can't resist to post a first Red/System 
source example:

#import [
	"kernel32.dll" [
		GetStdHandle: "GetStdHandle" [
		  	type		[integer!]
		  	return:		[integer!]
		]
		WriteConsole: "WriteConsoleA" [
		  	handle		[integer!]
		  	buffer		[string!]
		  	len		[integer!]
		  	written		[struct! [value [integer!]]]
		  	reserved	[integer!]
		  	return:		[integer!]
		]
	]
]

stdout: GetStdHandle -11
written: struct [value [integer!]]

prin: func [s [string!] return: [integer!]][
	WriteConsole stdout s length? s written 0
]

prin "Hello Red World!"

Ladislav, regarding Red being a REBOL dialect if Red's syntax is 
a subset of the data exchange dialect syntax: I fully agree.

Of course, this will be part of Red/System own small runtime, exposing 
among other functions, PRIN and PRINT.

How are the types of local variables declared in Red/System? The 
slideshow says no type inference...

As in REBOL: using /LOCAL followed by name and datatype.

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?