r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Dockimbel
31-Jan-2012
[4611]
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.
GrahamC
31-Jan-2012
[4612]
That would be wonderful!
Dockimbel
31-Jan-2012
[4613]
You can also add HTML5 to the list of future GUI frameworks. ;-)
GrahamC
31-Jan-2012
[4614x2]
Sure .. people can read the slide presentation, but a few words might 
help :)
HTML5 - browser plugin then?
Dockimbel
31-Jan-2012
[4616]
Huh? No need for such heavy beast, we have Topaz, remember? ;-)
Endo
31-Jan-2012
[4617]
Very nice plans Doc.
Dockimbel
31-Jan-2012
[4618x2]
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.
Evgeniy Philippov
31-Jan-2012
[4620]
Dockimbel: Re: native GUI - will this be X gui or you plan to write 
a native code for every card driver? ;)
Dockimbel
31-Jan-2012
[4621x2]
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.
Evgeniy Philippov
31-Jan-2012
[4623x2]
SWT uses GTK+.
On Linux.
Dockimbel
31-Jan-2012
[4625]
Really? No X backend?
Robert
31-Jan-2012
[4626x2]
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.
Dockimbel
31-Jan-2012
[4628]
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.
GrahamC
31-Jan-2012
[4629]
Saphirion could migrate to RED :)
Dockimbel
31-Jan-2012
[4630x2]
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. ;-)
Evgeniy Philippov
31-Jan-2012
[4632x3]
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*.
Henrik
31-Jan-2012
[4635]
I would personally want a View clone with a GUI dialect on top. The 
R3 GUI could be appropriate.
GrahamC
31-Jan-2012
[4636x3]
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 )
Dockimbel
31-Jan-2012
[4639]
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.
Evgeniy Philippov
31-Jan-2012
[4640x3]
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.
Dockimbel
31-Jan-2012
[4643x2]
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.
Evgeniy Philippov
31-Jan-2012
[4645]
no. the delimiter is space. it's ok.
Andreas
31-Jan-2012
[4646]
if you want to parse function calls into a call tree, you'd need 
some argument delimitations
Evgeniy Philippov
31-Jan-2012
[4647]
spaces are delimiters
Andreas
31-Jan-2012
[4648]
how do you parse `foo bar 1 2`?
Evgeniy Philippov
31-Jan-2012
[4649]
depends on the definitions of  foo and other tokens. I.e. on context
Andreas
31-Jan-2012
[4650x3]
exactly
so if you want a context-free grammar which models nested calls, 
you'd need funcall delimitation
(which is what doc said)
Evgeniy Philippov
31-Jan-2012
[4653x3]
no. not delimiters are issue.
end of list of arguments is uncertain
with CFG
Andreas
31-Jan-2012
[4656]
read again: i said "funcall delimitation"
Evgeniy Philippov
31-Jan-2012
[4657x2]
this is ambiguous
and nested calls are implementable without any delimitation
Andreas
31-Jan-2012
[4659x2]
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)