World: r3wp

Thanks Graham. Typo fixed.

Andreas, you can compile a large subset of code that REBOL would 
also accept. The underlying semantics would be different, but not 
enough so for it to matter to most programmers.

I was planning to use a desambiguation check on loading UDT with 
literal parsing rules, to avoid collision with other type's syntax 
and delimiters. It still need to be prototyped and tested with real 
code to see if it's worth it.

Brian: right, it will look and even feel very much like REBOL to 
most programmers that don't rely on higher level semantics and complex 
hand-optimized code.

I prefer code that can be loaded by a dumb loader, code that doesn't 
have different meanings depending on which module is loaded even 
before the code runs. I've had a lot of experience with different 
languages, and any language which requires you to read the source 
of its entire runtime library to debug properly is a bad one (I'm 
looking at you, Delphi and C++).

Do you have any prototype already? So we could see some code example?

One advantage to using the R3 data syntax is that you could have 
a Red dialect in R3 as an extension. It's up to you whether this 
is a value.

I have a working prototype of Red/System's tool chain (compiler+linker), 
but I need to clean-up the code first, add some runtime primitives 
(there's currently only PRINT and just working on string literals, 
so quite limited). I was thinking about making it available next 
week on github. Then I will start publishing every incremental revision 
there. I'll do an annoucement this week about that on Red's blog.

No reason why competing projects can't cooperate as well, licenses 
permitting :)

That "Too abstract code" section... With type inferencing you could 
manage abstract code. It might require declaring the types of function 
arguments before path syntax can be used, but that isn't as big a 
deal as it sounds.

In theory, you should be able to build some R3 extensions in Red/System 
(I would need to implement the DLL linker support and 3rd-party DLL 
exported functions mapping first).

It would also be possible to make the function argument type syntax 
more complex than that of R3, providing more detailed information. 
On the other hand, duck typing may be sufficient to determine what 
is necessary.

Brian: true, I'm not yet sure how far the inference engine could 
push the limit without becoming too complex to maintain, so I've 
put this early warning to show that there will be a limit (even I 
don't know yet where it will be precisely).

And that limit could be increased with time.

I like Go's type system, where there are interface types but you 
don't have to declare that your objects implement those interfaces. 
The type checker can figure out for itself whether the object matches 
any interface type. It's like formalized duck typing. Go's object 
model - no classes or inheritance - adapts really well to REBOL, 
so it's a good language to mine for ideas.

And that limit could be increased with time.

 Exactly. As Red's compiler will be coded in Red (once the bootstrapping 
 phase will be over), every new feature added to Red will benefit 
 to the compiler itself.

Go: It's in my scope of languages to study, like Scala, Lua, Factor 
and Rust.

Falcon :-)

Ah yes, I'll add that one too to my list. Thanks for the reminder 
:-)

Andreas: "Except that if Red (not Red/System) is to be statically 
compiled as well, that'll make the language quite different to REBOL. 
In fact, I'd assume that except for some superficial syntactic similarities, 
it won't have much to do with REBOL at all." - nevertheless, if Red 
will be a sublanguage of what I call the Data Exchange Dialect, it 
will be a REBOL dialect in my opinion, no matter how limited/unlimited 
it is going to be.

Althought not precisely undestanding the topic, I might agree with 
Ladislav. Now if I am not wrong, then e.g. Cyphre's JIT code could 
be regarded being kind of REBOL dialect - it looks like REBOL, it 
might have syntax like REBOL, you just can't do all the tricks with 
it. Whereas we could not say the same about e.g. a RebCode? Does 
it make sense, or am I wrong?

Whereas we could not say the same about e.g. a RebCode?
 - actually, we could say the same about RebCode as well

Doc, you might also consider making your type inferencer aware of 
the ASSERT function. ASSERT/type in particular would provide useful 
information, and can be evaluated statically as long as you don't 
let the function be overriden.

Quick questions about Red/System:

- Do you have DO of block expressions (getting from a word, returning 
from a function), rather than scripts or inline blocks?

- Are the conditional control and loop functions built into the language, 
or are they functions?

- Can the aforementioned functions take block expressions, or only 
inline blocks?

ASSERT: I'll look into that.

DO of block expressions

 nope, it's too high-level for Red/System. Remember that there's no 
 block! datatype in Red/System, we're talking about a C-level language. 
 In Red, you'll be able to use DO (as well as REDUCE and COMPOSE) 
 pretty much the same way as in REBOL (will require the JIT).


Control flow functions: built into the language for Red & Red/System. 
They'll be expecting inline blocks as argument, but when the JIT 
will be available, this could be extended to block expressions.

Doc: LuaJIT.org may have some good parallels as well just LUA

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.