World: r4wp

Jerry: command!, end!, frame! and rebcode! are very unlikely to be 
adopted in Red. Also following will probably not be part of Red too 
(or not in a near future): event!, gob!, handle!. Meaning of decimal! 
will most probably be changed, float! or real! will be used instead. 
Money! will receive a different treatment than in REBOL (number of 
digits after comma will probably be adjustable).


Also, expect the return of hash! in Red, and new datatypes that do 
not exists in REBOL.

As you can see, it is not a 1-1 matching between Red and R3.

Routine! will also probably be back in Red.

I agree with Peter, you can't measure Red's progress by taking R3 
as a target goal. It is better and more accurate to measure progress 
by counting what is built in Red.

struct! doesn't work in R3

task! seems to work half or so

As far as I know, utype! doesn't work

rebcode! is not implemented in R3

Doc - interesting - I know you have no intention to port View, but 
what about other types of events? Will not be there an event type? 
I want my wait-list with various events - networking, serial port, 
whatever :-)

Kaj, rebcode! isn't really in R2 anymore either. But the mechanism 
that was used to make rebcode fast in R2 has been implemented in 
R3, and it used by the R3-GUI dialect. Anyone could implement their 
own rebcode if they like, even with improvements. That mechanism 
would be worth supporting in Red.

Hopefully less buggy too. The rebcode dialect caused a lot of crashes 
and security holes, which is why it was removed. The new mechanism 
doesn't have that problem.

Petr, I haven't decided yet how events will be presented to user, 
there are different possible options and the choice will depend on 
the implementation constraints. Once we have the I/O + tasking implemented, 
we'll see what interface is the best for exposing events to user.

Too bad about command!, that function type is the best one for pluggable 
JIT compiled function models. There are other advantages too.

Let's not rehash the hybrid extension conversation though :)

For handle!, what type are you using to be an opaque pointer-sized 
type that all pointer operations are prohibited on? Can such a thing 
be typedefed?

If you had an ability to create an opaque value of any size that 
will fit in a value slot, or maybe just limited to pointer size, 
only accessible from Red/system code, that would be a good replacement 
for handle!.

I haven't decided on that yet. I need to implement first the type 
marshalling interface between Red and Red/System and see then, what 
is the best option.

Interesting info, Brian. However, I wonder what rebcode! would be 
needed for when you can inline Red/System

The advantage to rebcode isn't that it's fast, it's that its semantic 
model is similar to assembler. That makes it useful for a lot of 
interesting problems. Also, there might be times when you don't want 
to allow Red/System to be inlined - it's basically the same as unsafe 
code in C#, with the same security characteristics.

Yes, but RebCode is aimed at an interpreter. In Red we can make any 
safe dialect we want that compiles to Red and/or Red/System

If Red's compiler is implemented well, there shouldn't be any reason 
that it would be slower than the equivalent Red/System code. Red/System 
is just less safe.

In Red, there might be an advantage to making a compiled rebcode 
equivalent (but without the stability and security bugs). Unlike 
REBOL (ignoring the debate), rebcode is inherently compilable. It 
wasn't designed to be interpreted the way REBOL was. It just had 
a fast interpreter implementation, which has been adapted to other 
dialects in R3.

Right, found it, the DO-COMMANDS function. That is what implements 
the rebcode interpreter model. And it's another reason to have a 
command! type.

Sure, but Red and Red/System are also inherently compilable. I think 
there's very little advantage left in a virtual assembly dialect

Inherently compilable

 alone still leaves open a wide range of design possibilities. "Redcode" 
 could still explore design spaces opened up by a quite reduced source 
 language.

I guess the intermediate format in Red/System 2 will get you that

Yes, possibly.

Inline that, and presto: RedCode

BrianH: is the command! dispatch interface the same as DELECT?

DELECT takes a dialect that prepares the commands

Doc, regarding decimal!, do you mean the implementation will be different, 
or are you planning to use float! or real! as the datatype name?

The latter. I would like to keep decimal! name for a new BCD datatype.

I want to compliment you on the speed of development of Red! It is 
truly amazing. Keep up the good work.
Is this news also worth mentioning on the red-lang.org website?

Thanks Arnold. Not yet, I will make a 0.3.1 release for that, but 
it needs a few more days to stabilize.

FYI, I have started working on EXIT and RETURN implementation. It 
will probably take a day to design and implement them correctly. 
In the meantime, feel free to push issues with Red functions on the 
bugtracker.

Haven't read commints, so sorry if already answered - will there 
be a FUNCT equivalent, allowing to use local words only?

FUNCTION. It's mentioned here: https://github.com/dockimbel/Red/commit/cc5c8dcb839572bb25559f964ed7d30419cb5a31

Thanks Doc. I support the idea of decimal! as the BCD type.

Doc, I can see Rudolf being pretty active with testing Red, Red/System? 
Nice, I thought we have lost him when R3 went into a non-development 
mode ....

He showed up again shorter after Red first alpha release. He's working 
on updating the BNF grammar of Red/System to add namespaces.

No gob! Does this mean no GUI or just gui done in different way?

There are GTK+ and SDL bindings. There will be bindings to native 
GUIs in the future (I consider GTK to be the most native binding 
for Linux and BSD systems)

They're for Red/System for now, not connected to Red yet

Does this mean no GUI or just gui done in different way?

 See all the presentation slides for Red, a native GUI system will 
 be provided. Also a web server with a new web framework will be part 
 of Red stack, so modern style web apps will be supported.


The GUI will probably be done in different way than R3 underneath, 
maybe a gob!-like datatype will be a good match, but such implementation 
detail is not known until implementation starts. Also, it is possible 
to extract R3 GUI code, wrap it in a shared library and plug it in 
Red (but I won't be the one doing that and maintaining such wrapper).

As Kaj underlined, GTK+ will most probably be the native target for 
Linux.

I've finally been able to write a Red version of Fibonacci numbers. 
It executes twice as fast as R3

Red/System is roughly hundred times faster

Is the Red version pure Red? Why exactly is it faster than R3?

It's compiled

parameter: 35

fibonacci: func [
	n		[integer!]
	/local	a
][
	either n < 2 [
		n
	][
		a: fibonacci n - 1
		a + fibonacci n - 2
	]
]

prin "Fibonacci "
prin parameter
prin ": "
print fibonacci parameter

Functions in red are not compiled yet, right ?