• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

BrianH
20-Nov-2012
[4153x3]
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.
Kaj
20-Nov-2012
[4156]
Sure, but Red and Red/System are also inherently compilable. I think 
there's very little advantage left in a virtual assembly dialect
Andreas
20-Nov-2012
[4157]
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.
Kaj
20-Nov-2012
[4158]
I guess the intermediate format in Red/System 2 will get you that
Andreas
20-Nov-2012
[4159]
Yes, possibly.
Kaj
20-Nov-2012
[4160]
Inline that, and presto: RedCode
Pekr
20-Nov-2012
[4161]
BrianH: is the command! dispatch interface the same as DELECT?
Kaj
20-Nov-2012
[4162]
DELECT takes a dialect that prepares the commands
Gregg
20-Nov-2012
[4163]
Doc, regarding decimal!, do you mean the implementation will be different, 
or are you planning to use float! or real! as the datatype name?
DocKimbel
20-Nov-2012
[4164]
The latter. I would like to keep decimal! name for a new BCD datatype.
Arnold
20-Nov-2012
[4165]
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?
DocKimbel
20-Nov-2012
[4166x2]
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.
Pekr
20-Nov-2012
[4168]
Haven't read commints, so sorry if already answered - will there 
be a FUNCT equivalent, allowing to use local words only?
BrianH
20-Nov-2012
[4169]
FUNCTION. It's mentioned here: https://github.com/dockimbel/Red/commit/cc5c8dcb839572bb25559f964ed7d30419cb5a31
Gregg
20-Nov-2012
[4170]
Thanks Doc. I support the idea of decimal! as the BCD type.
Pekr
21-Nov-2012
[4171]
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 ....
DocKimbel
21-Nov-2012
[4172]
He showed up again shorter after Red first alpha release. He's working 
on updating the BNF grammar of Red/System to add namespaces.
kensingleton
21-Nov-2012
[4173]
No gob! Does this mean no GUI or just gui done in different way?
Kaj
21-Nov-2012
[4174x2]
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
DocKimbel
21-Nov-2012
[4176x2]
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.
Kaj
22-Nov-2012
[4178x2]
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
Henrik
22-Nov-2012
[4180]
Is the Red version pure Red? Why exactly is it faster than R3?
Kaj
22-Nov-2012
[4181x2]
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
Steeve
22-Nov-2012
[4183]
Functions in red are not compiled yet, right ?
PeterWood
22-Nov-2012
[4184x2]
Wrong.
Functions are compiled  in Red.
Steeve
22-Nov-2012
[4186]
I talk about Red not Red/system
Kaj
22-Nov-2012
[4187]
Yes, Peter i right
PeterWood
22-Nov-2012
[4188]
Me too!
Kaj
22-Nov-2012
[4189]
is
Steeve
22-Nov-2012
[4190]
I think you're both wrong ;-)
Kaj
22-Nov-2012
[4191]
Red is a compiler, as simple as that
PeterWood
22-Nov-2012
[4192]
Well I'm usually worng :-)
Steeve
22-Nov-2012
[4193x2]
You're talking 	about Red/system not Red
Red is evaluated
Kaj
22-Nov-2012
[4195]
No, we've been publishing that fact for almost two years now. I don't 
know what else we can do
Steeve
22-Nov-2012
[4196]
like Rebol
PeterWood
22-Nov-2012
[4197x2]
No, it is compiled like C.
This might give you a clue - https://github.com/dockimbel/Red/issues/308
DocKimbel
22-Nov-2012
[4199x2]
Kaj: nice! Actually, such kind of function (highly recursive, very 
small body) should perform 5-10 times faster than R3 in the target 
compiler. Functions with bigger bodies shoud be in the 10-15 range. 
Functions with pure math expressions should be in a 20-100 range.


Though, these are very rough early estimates I did on the base of 
a few micro-benchmarks.
Red is evaluated
 No, compiled. :-)
Steeve
22-Nov-2012
[4201]
why is kaj's script so slow then ?  ;-)
Kaj
22-Nov-2012
[4202]
No optimisations