World: r3wp

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

( though I have this nagging suspicion a dialected GUI trades ease 
of use for sophistication and flexibility )

That will be the real challenge, define a GUI dialect good enough 
to cover the common parts and backend-specific extensions for been 
able to fully use backend-specific features.

Well. The grammar is definitely not LL(1) and not context free at 
all since it depends on context. (E.g. when calling functions with 
fixed number of arguments.)

It needs to know how many arguments the function takes.

That's non-context-free. Though this lexer can be done in Coco/R.

I guess that a context-free grammar would have required some arguments 
list delimiter, such as C and most other languages have.

Also, the "Each context-free rule" expression on page 1 of the BNF 
grammar description is not accurate, it would need a specific comment 
for <fixed-arguments-function-call> rule.

no. the delimiter is space. it's ok.

if you want to parse function calls into a call tree, you'd need 
some argument delimitations

spaces are delimiters

how do you parse `foo bar 1 2`?

depends on the definitions of  foo and other tokens. I.e. on context

exactly

so if you want a context-free grammar which models nested calls, 
you'd need funcall delimitation

(which is what doc said)