World: r3wp

yes... just tested... it works

I am currently entering a formal EBNF Coco/R .ATG grammar for Red/System 
as specified in the BNF doc at the site.

Coco/R is LL(1)/LL(k). This grammar would automagically yield a new 
lexer for Red/System.

The Coco/R is GPL. The compiler/lexer produced by Coco/R is of unspecified 
license.

Typed in. Several dozens of LL(1) warnings.

Good as long as there's no error. ;-)

Just remind me please .. when is work starting on RED itself?

Dockimbel - those warnings mean ambiguities

I currently try to resolve them

Is http://www.red-lang.org/p/roadmap.html
Bootstrap 4 referring to the RED language?

In the roadmap, Red refers to Red proper, Red/System to Red/System. 
Easy as pie :)

So yes, bootstrap steps 3, 4, 5 refer to implementing parts of Red 
proper.

Evgeniy: you can email the fixes to Rudolf directly or to me ([nr-:-red-lang-:-org]).

Graham: it should have started a month ago, but I've postponed it 
to add floating point support to Red/System. The work on Red should 
start in a week.

If the grammar is OK, there will be new interpreter for Red/System 
soon :)

Ok, thanks guys

Evgeniy: we'll see how far can go Coco/R. :-)

It would be nice for newbies in the about page to have a statement 
of what you will be able to do with RED when "complete"

eg. system utilities, web apps, cgi scripting, desktop apps ..etc

And if there's a plan for a GUI

I suppose there are some internal priorities for Red as well, such 
as when for example networking becomes relevant.

I would hope Red adopts one of the existing GUI solutions.

As opposed to writing a dialected GUI?

Newbies info: well, from all the presentations slides, you can see 
that Red is meant to be a "general purpose" programming language, 
so making any list of possible applications would be restrictive 
and probably also premature as Red is not yet implemented.


GUI is certainly a feature to have, but I wouldn't make it part of 
the "core" language, rather handle it as library. One remark about 
future Red GUI support, there will probably be several GUI frameworks 
available (we already have GTK+, I'll add a native one, and someone 
could contribute a View clone), I'll try to put a common VID-like 
dialect on top of them, so we can quickly switch from one to another 
with minimal changes needed.

That would be wonderful!

You can also add HTML5 to the list of future GUI frameworks. ;-)

Sure .. people can read the slide presentation, but a few words might 
help :)

HTML5 - browser plugin then?

Huh? No need for such heavy beast, we have Topaz, remember? ;-)

Very nice plans Doc.

Also, there are several good high-level widget sets on top of HTML5 
that we could use as back-ends for client-side GUI, like Extjs and 
jQueryUI.

REBOL-like languages are especially good at code generation, so we'll 
use that ability to abstract as many GUI API and frameworks as possible.

Dockimbel: Re: native GUI - will this be X gui or you plan to write 
a native code for every card driver? ;)

BTW, we could also make the View face/gobs hierarchy a common layer 
on top of all those GUI frameworks, if the overhead is not too high.

Evgeniy: you're sounding like you're volunteering for writing the 
X back-end, thanks, that would be nice! ;-))


The native GUI I have in mind for Red is a SWT-like one, but as light 
as possible (SWT has some really heavy widgets). So, yes back-ends 
for Win32, X, Cocoa and Android are planned. The Cocoa and Android 
back-ends would need obj-c and java bridges.

SWT uses GTK+.

On Linux.

Really? No X backend?

Since we either do a Lua GUI or perhaps can adopt Red ;-) and do 
the GUI there, I think there will be some choices.

The R3 host-kit is a good source for how to do it.

Xlibs are a nightmare to work with for me, at least last time I had 
to use them at university 20 years ago, I don't think it has changed 
much since then.

Saphirion could migrate to RED :)

Robert: I hope Red can be ready fast enough for you, so that all 
those REBOL experts you've hired could continue to make wonders in 
a REBOL-like language. :-)

Oh, I forgot to mention Flash also as a possible back-end for GUI, 
if Oldes makes the AVM2 port for Red/System some day. ;-)

Dockimbel: I don't really know about SWT itself, but Eclipse on Linux 
is always shipped with SWT over GTK+.

Based on SWT over GTK+.

It does not ship *with*.

I would personally want a View clone with a GUI dialect on top. The 
R3 GUI could be appropriate.

Makes sense to re-use as much of the R3 GUi work as possible

So, Red/GUI is complete and awaiting RED