World: r3wp

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)

no. not delimiters are issue.

end of list of arguments is uncertain

with CFG

read again: i said "funcall delimitation"

this is ambiguous

and nested calls are implementable without any delimitation

on the other hand, i'm certain that you can model Red/System's syntactical 
structure with a context-free grammar. it's just that the CST/AST 
would look quite different from other languages (i.e. in that it 
does not explicitly model function call structures)

(pretty much the same as for REBOL)

you're wrong

for example

as i've done this several times before, i'm quite confident that 
i'm not wrong :)

funcallA arglist next_token ----- CFG grammar cannot distinguish 
args from arglist from next_token.

you probably used hacks over CFG that make it non-CFG

arglist --- args separated by spaces

no. as i've said before, you simply cannot explicitly model e.g. 
funcalls

i.e. you won't get a "funcall" node in the AST