AltME groups: search

It doesn't scale well, and as you can see in the following example, 
it can quickly get nasty:


    [/external obj1 [a b] /external obj2 [c d] /external obj3 [e f] /global 
    g h]

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

I guess the intermediate format in Red/System 2 will get you that

You can get Red/System speed if you write in Red/System, not if you 
write Red

Red is a high-level language with high-level abstract types. Once 
we get optimizations, Kaj's example should run 5-10 faster than R3. 
For some high-level expressions that have low-level counterparts, 
it is possible to achieve very high gains (in the 10-100 range), 
for those that do not have low-level counterparts, you can only expect 
typical gains from moving from an interpreter to a compiler (on average 
5-10 faster).


Also, there is also a source of additional speed gains: the possible 
runtime optimizations enabled by the JIT-compiler.

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.

Now that you mention it, I remember seeing that code. Such code won't 
compile until we get JIT-compilation.

I would certainly wonder why you stop at FIFTH.

Why stop at TENTH? :-)

It doesn't make much sense to me to add features that nobody will 
use, just because we can add it, doesn't mean we should. For beginners, 
if they can't get a good picture on picking values with accessor 
up to FIFTH, I can hardly think that adding more will be of any help. 


The only reason for having them is the above code pattern used by 
Carl, but it can't be used for now in Red. Also, users are free to 
add more accessors names in their own code if they feel the need 
for it.

I have my Raspberry Pi now (And an Arduino uno board too). Only have 
to wait until I get it from Sinterklaas now before I can play with 
them.

Arnold, you can support a complete chinese or spanish version of 
R3 using a module and those worda: :wordb value assignements, no 
ALIAS required. But it would be a mistake to do that for educational 
purposes, because it would get in the way of them learning regular 
Rebol/Red code. You might want to do that for non-educational reasons 
though.

aliases can be used with refinements which is a bit weird 

>> alias 'any "xxxxxxx"
>> get/xxxxxxx 'red
== 255.0.0

Also, REBOL-like languages are easy to generate from a dialect. A 
translator could write data files in a dialect, which could be used 
to generate the wrapper functions and assignment statements. And 
a half-way decent optimizer could get rid of the wrappers using the 
same methods that would allow it to statically resolve refinements. 
There's no reason to support an astoundly worse method.

I have to wait to start programming my Raspberry Pi until I actually 
get it from Sinterklaas. After that I can try to test Red on it. 
I watched your presentation on programming in Red on the Raspberry 
Pi. No Syllable yet? WHat Linux did you use on the Rasp again Kaj?

Actually, when you use a typed constructor function, you already 
get access to the arguments array, but it's an array of stuct!s of 
type typed-value!

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. 


I don't get this part...Your program seems to be still running while 
you think it has finished.

The cool stuff to show-off would be - bring your Red on your SD card/USB 
stick, plug-it-in, go to its dir = show "no-instal" option, show 
some GUI dialect, press a button, generate android app, and with 
one command or a dialect, push it to Google play. Then I can send 
you my friends short/long description, how long it took him to get 
his app there, downloading and installing all the JAVA crap and all 
dependencies ...

A couple of observations: I would think that the slow going with 
View had a lot to do with the size of the community as well as an 
architecture that didn't easily permit the use of vector graphics, 
preferably designed using external tools, for drawing widget states. 


WRT Red, it makes sense to use native controls in order to get off 
the ground quickly, but the UI subsystem should allow for owner drawn 
controls. By allow for, I mean that these should be able to exist 
side-by-side with native controls, and, if defined using a vector 
source, widgets should do bitmap caching at the appropriate times 
for better performance. I guess what I'm saying is to please think 
about how owner drawn widgets would fit into whatever is the initial 
implementation.

I agree with Henrik 90%. The hard part is picking the target app 
and important elements. A game, or modern app with animation elements 
is a very different target than an "efficiency above all" business 
app. One of my failed attempts with REBOL was to get Carl, for just 
this reason, to identify a target audience. It guides your design. 


In the case of a Red/REBOL GUI, maybe there is no single design or 
dialect. Making small apps simple is hard to match to the needs of 
complex apps. If you're writing database/CRUD apps, wouldn't it be 
great to have a toolset designed just for that? That same toolset 
won't work well for games though.


I think using an IDE as the first target app is a *fantastic* idea. 
It covers a lot of areas, including the possibility of building on 
an extensible app framework (something lighter than Eclipse :-), 
files, documents, workflow, tool integration, customization, and 
many UI elements. And *we*, developers, are the target audience.

Of course, I prefer REBOL data, with makedoc being my preferred markup 
format. I don't know if Carl's WIP wiki is worth asking about, or 
another wiki engine or site would not lock us in too much. Some of 
us did some work on a wikimedia interface for R3 docs, which didn't 
get far. And I have a wikidot site we can play with if people want.

And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...

Pekr: you don't get the right picture. When I mention "native widgets", 
I am mainly referring to the ones provided by each OS, which is what 
most users expect to find in an app for their OS, and what most developers 
wants, is to provide a consistent experience for users. So, actually, 
such approach will be lighter then /View, because the OS provides 
you with everything you need. In the case of Linux, GTK is the main 
standard and it is built-in many distros, so that is the one we will 
probably use for Linux target and you don't need to provide it with 
your app.

I tried to attract Cyphre, unfortunatelly he has new View like engine 
in mind, which would require some extensive resources to spend to 
get that. And I don't have such resources, so I am "a bit" nervous 
:-)

Doc starts with a kind of dialect - some midd level. Kind of what 
Henrik called top-down, but with good thinking ahead. you mostly 
write VID-like dialect, which would get (not necessarily 100% automatically) 
compiled to target platforms. So on Android, it looks like andorid, 
etc., but also - for small embedded - either html5, or View ...

Petr, don't lose focus. The train is going in your direction. Just 
get out of the way. :-)

Gregg - no need to make me look dumb. My wishlist.txt is just one 
line - get the small cross-plaftorm View like engine for Red available 
too - it might be attractive to many ppl, easy as that ;-)

As far as the wish for a View/VID native solution goes, I wish that 
as well. Maybe it will be possible when the JIT compiler becomes 
reality to easily adapt Rebol's VID. 

It does not have to be complete like VID, a basic set of widgets 
will get you a long way.  

Other solutions are a really good thing too, but looking at GTK and 
myself I find it hard to find out how to get GTK on my mac. It is 
not a standard dmg file I can download and install and it works. 
Other GUI solutions require integration of their package or having 
the end user of your programs to find out how to get it running on 
their machine. That kind of thing can be a real showstopper to global 
acceptance.


I know Doc is working hard and has already stated he intends to come 
up with a VID like native solution. So we can let him focus and be 
silent ,or we can comment and discuss letting him know we do care.

A mention about THROW function attribute: I will add support for 
it, but it won't be usable until we get  dynamic function creation 
support.

Thanks, I need first to get a Visa, so it is not done yet.

The lexer is choking on get-word used in path...let me see that...

Steeve: I have fixed the lexer bug, so it should at least load correctly 
now. But paren! in path are not yet compiled, so you'll get a "feature 
not implemented" at compilation.


Also, passing a function as argument is not yet correctly handled. 
Also I'm unsure if s/:step: will be compiled correctly, as we haven't 
yet much tests for path accesses.

the following are currently invalid REBOL notations (the first three 
load in R2 but get scrambled)

I prefer the first tree, since they are pretty obvious without any 
knowledge of the language.

16#FFFF000F
8#7124554764
2#0110110101

H#FFFF000F
O#7124554764
B#0110110101

How do one know a rebol function is supported or not ?

 Currently, only by looking in the source code. The compiler is lack 
 a lot of checks, so you need to get your Red code right for now.

What about to convert all the words into lowercase in compile time?


Words values are not "compilable", they are data (words used as variables 
can be "compiled" to some extents). Converting all words into lowercase 
during compilation (including JIT-compilation for words constructed 
at runtime) would make you loose the ability to distinguish lower/upper-cased 
letters, leading to big issues and pitfalls in the language. For 
example: (form 'A) = "a" (beause 'A would get converted to 'a). Not 
an option.

Yes, that's what I meant. I phrased it that way because there was 
a big discussion where people were requesting that an option be added 
to objects to have them be case-sensitive, to distinguish based on 
case when mapping words to value slots, rather than the case-preserving 
default. We had to reject that proposal because there was no way 
to specify that option in the make object! syntax. The only way to 
do that in Rebol is to have a separate object-like datatype that 
has case-sensitive word mapping. The same proposal was made for maps, 
with the same results: a case-sensitive alternate type would be required. 
For both of those types, SELECT vs. SELECT/case could have some meaningful 
distinction, though we didn't get far enough for that to be an issue 
yet.

Red development is on the Jazz. Don't get distracted by the release 
of R3 sources. Keep rolling the Red dice :)

Janko, every bit counts. I've donated this month, but I will match 
December donations in a January donation, up to USD$200. So, donations 
in December get double matching up to USD$200, if Nick matches as 
well.

Red 0.3.1 released: http://www.red-lang.org/2012/12/red-v031-functions-support-added.html

- function support
- path get/set notation support
- refinement support for native functions
- expressions in parentheses compilation

- new datatypes: function!, paren!, path!, lit-path!, get-path!, 
set-path!

- new actions and natives: find, select, copy, reflect, type?, halt,...

- extended mold, form and comparison operators to all new and existing 
datatypes
- many new mezzanines functions

- modulo and remainder operators on floats implemented for ARM backend
- Quick-Test testing framework ported to Red
- a truckload of new unit tests
- many bugfixes
- about 200 new commits to the Github repository
- updated Red/System formal description document

I would like to get rid of it, for many reasons. Firstly because 
it was not meant to be part of Red/System, but added later for practical 
needs, secondly because Red/System code could be built/composed more 
efficiently from Red.

Pekr: thanks, I hope to get the device + SDK in January. My application 
to their developer program was based on an innovative IDE for Red 
powered by Leap Motion device. ;-)

### Red/System Question ###
To get cpu count, I can do this in C:
   
   sysctlbyname("hw.ncpu", &cpuCount, &len, ((void *)0), 0);


But Red/System doesn't support &. How can I do this in Red/System? 
Thanks.

Red/System Questions:


I am translating a piece of code from C to Red/System, I don't know 
how to translate the following C code:


success = OSAtomicCompareAndSwapPtrBarrier(NULL, newzone,  (void 
* volatile *)&_zone_); // C

my problems are: 

1. In Red/Sys, _sqliteZone_ is a struct! (which is a pointer in Red/Sys), 
so I cannot use :_zone_ to get it's address.
2. "(void * volatile *)" in C => "as byte-ptr!" in Red/Sys ??

Thanks!

1. _zone_ is a struct pointer. I need to pass a pointer to a struct 
pointer as the 3rd parameter, that's why I try to use get-word here.

For 1., you can achieve it this way:

    s: declare struct! [n [integer!]]
    p: declare int-ptr!
    p/value: as-integer s

then `p` becomes a pointer on `s`.


I might extend get-word syntax to struct! and pointer! too, someone 
just needs to add a ticket to Github to remind me of that.

Speaking about atomic operations, any thought to get them in Red/System? 
I could use them well

BREAK will probably be implemented before 2.0 (not sure for CONTINUE). 
So, you can't break from a loop currently. 


As a workaround, you can EXIT/RETURN instead. So if you write your 
loop in a separate function, you'll get similar effect as with BREAK.

The console is currently just a Red script, once we get devices and 
ports, it will be replaced by a proper console:// port.

Right, if you bench from the console, currently, you're just measuring 
the speed of the interpreter. When the JIT will be there, loops from 
the console might get JIT-compiled, so it will be even less relevant 
to bench from the console. My plan since the beginning is to add 
a profiler to Red, so you'll be able to make precise comparisons 
whatever way the code is run.

brianh - imo noone can get acustomed to that weird windows black 
crap :-) R2 is better experience. Carl admitted, that he might return 
r2 console to r3 codebase, and let ppl to develop it further ...

Now, if we can get Doc enough funding, he may be able to direct some 
of it to people he can work with, which would be great, and we can 
set up bountys as well.

@Doc : I never thought you would do so much work in a so short time. 
If my support can help you a bit to go further and leave behind - 
with the help of the other donators - the bad feeling of having to 
work elsewhere to  get money for your living, then it's a pleasure 
for me to do it as much as I can.  Keep up the good work Doc and 
have a happy new Year form Quebec, Canada.

Kaj: congrats on the first binding made available to Red! :-)


I've noticed in %examples/do-sql.red the comment for #include:  "FIXME: 
#252". Actually, #252 is for Red/System, Red  implements its own 
#include which behaves differently than the Red/System version. I've 
tried to make it more intuitive, but it still needs some adjustments, 
so feel free to open new tickets about that (with simple concrete 
test cases I can reproduce). 


Also keep in mind that #include at Red level is intended to be a 
temporary feature until we get DO, LOAD and READ working with files. 
I would like an include system that could work both for the interpreter 
and compiler without having to change any code. I'm not sure this 
is achievable, so in worst case, we'll keep #include as fall-back.

You should wait for me to add the marshalling and unmarshalling functions 
(that will be used everywhere Red needs to interface with non-Red 
code). In your code example, it should be: 1 + length? version (as 
it needs to account for terminal NUL character). Also, you need to 
get sure that the source c-string! buffer is always available or 
make a copy of it (a pointer to it is stored as a UTF-8 cache, unused 
yet, but intended for speeding up I/O, still experimental, not sure 
it will stay for v1.0).

Since Red compiles to Red/system, how can I get the red/system source 
result?

Red is simpler to use but sometimes we want speed so why not let 
red compile to r/s

and then use that source to make a routine! or as a stand-alone program?

I'll get around to reporting some issues later tonight

An altenative for preprocessor command could be
.if
(It starts in column 1 doesn't it?)

On the other hand isn;t it possible to get the meaning from the context? 
#if #define etc could be preversed preprocessor words?
(or I am on a complete other level again this time)

Still, I'm sure I could get used to keyword! as it could be interpreted 
clearly in the different contexts where issue! is used today.

Actually, every statically defined Red function will get compiled, 
only functions created at runtime will be passed to the interprerter 
(or JIT-compiled).

We could remove the body block of compiled function! values, yes, 
so it doesn't get added to the executable. That could be an optional 
switch that would also disable undefine 'body-of accessor.

Well, I try to switch to dark themes to both save powers and my eyes. 
;-) 


I've provided a switching option to more classical "light" theme 
for the docs, but doing the same for the web site was too much work 
for me, so I've left it with the dark theme only. I will fix that 
once we get a new web site for Red (or if someone skilled enough 
can make the changes, I'll be glad to push them online).

Arnold: if you use DECLARE on pointer! or struct!, you already get 
an automatic memory allocation done by the compiler for you. Such 
memory will be statically allocated from the data segment (defined 
by the executable). 


Alternatively, you can use ALLOCATE to get a memory buffer for your 
array during the execution of your program (just don't forget to 
release it with a FREE call at some point).

The Rde presentation shows the use of the binary Red. In it shows 
how to compile to get a cgi and a dynamic library. Are these also 
implemented in the current compile scripts? In that case that holds 
a good argument to update the Redcompiler.r script. It needs some 
work anyhow I noticed, it is rather location dependent atm.

Red []

#include %GTK/GTK.red

view/title [
	text: area
	button "Do" [
		unless any [
			none? script: get-area-text text
			empty? script
			empty? code: load script
			unset? result: do code
		][
			prin "== "
			probe result
		]
	]
	button "View" [
		all [
			script: get-area-text text
			not empty? script
			not empty? code: load script
			view code
		]
	]
	button "Quit" close
] "Red GTK+ IDE"

Bo - R/S is low level - mostly a wrapper to C to enable Red like 
syntax. It will not contain stuff to open files and do more advanced 
things imo, unless you link to some library and create a wrapper 
for such a purpose. I am too eagerly waiting for Red to get more 
advanced stuff. I think, that once Doc finishes the interpreter stuff 
ec., he is back to objects/ports, and then networking/files IO will 
come and more fun begins :-)

Some optimizations will be very difficult or impossible to do if 
Red/System is used as the intermediate language, because those optimizations 
sometimes depend on the semantic model of the intermediate language, 
and Red/System doesn't have the semantic model of a compiler intermediate 
language. Optimization is hard work and people get PHDs for doing 
it. We can hope to catch up with modern C compilers, but don't expect 
it. One advantage is that Red is a high-level-enough language that 
an optimizer can make assumptions that a C compiler can't, so it 
is possible that we could get better code - it depends on the language 
and how much time we want to allocate on optimization.

It is. :-) If you run the download.r script, you'll get it automatically

You're right about LDA #. :-) It's also $A9. I had the same problem, 
wrote a disassembler in Atari BASIC until I could get hold of an 
assembler, so also have a considerable part of my brain dedicated 
to such numbers :-)

With the following code:

#include %GTK.reds

with gdk [
	err: declare struct! [value [g/g-error!]]
	myimg: load-image "image.jpg" err
]

I get the following error:


*** Compilation Error: invalid literal syntax: [value [g/g-error!]]

If I change it to:

err: declare struct! [value [c-string!]]

I get the following error:


*** Compilation Error: argument type mismatch on calling: gdk/load-image

*** expected: [struct! [value [g/g-error!]]], found: [struct! [value 
[c-string!]]]

cycle: func ["Cycle a series through its index."
	'series [word!]
	/local s
][
	either tail? s: get series [
		set series  next head s
		first head s
	][
		set series  next s
		s/1
	]
]

It would be possible to support it in the compiler too, but that 
would require that the `h` argument get declared with a type definition 
like: 

    g: func [h [function! [a]][...]

(not implemented yet though)

well, Bo, explained it better. I am not saying that you are not planning 
it, I was just asking, if it is planned, because other point of view 
might be, that we will get some very core funcionality, plus millions 
of nice wrappers, but that would make a different feeling ...

As we discussed before, you can get JPEG data from the GDK binding, 
but you have to finish the struct definition

@Kaj: I'm trying to get the JPG data without having X11 installed. 
 If I were to do something with LibJPEG directly, I would try to 
make it look like the R3 image! datatype.

Sorry Doc, it is hard to get-and-keep up to what you all achieve!! 
(And Kaj too) Even though I myself have less hours at my job I do 
not have as much time to follow it all. (More projects and chores 
in and about the house to do now and less 'spare' time at work for 
a quick review.

I will try to answer the question of how I see possibilities to make 
Red more suitable for funding. And have it get the attention a first 
proper release needs. Everybody else is hereby invited to think along 
how to make this possible.

RaspberryPi coming in luxury blue version - wonder, when we get Red 
one? :-) http://www.engadget.com/2013/03/04/raspberry-pi-coming-in-limited-edition-blue/

I was trying to evangelize Red/System to the Raspberry Pi forums 
today, but found it difficult to point them to a "here's how you 
get started" page.  That would be the perfect thing for a "Downloads" 
page on red-lang.org.

here's how you get started

 page" is Github Red page. There you have links for downloading an 
 archive or cloning the repo and all step-by-step instructions to 
 get you started.

Doc - I was quite surprised with your argumentation. I really don't 
know, if we are so much in an IT, but are you guys serious, that 
for normal user, in order to just give some tool a try, such user 
should use systems like Fossil or Git? I find myself competent enough, 
but unless new Windows client appeared, it was just nightmare to 
get things going, especially if one does not feel the need to understand 
all that pull/push etc. stuff.

Pekr: Agreed...that was my initial suggestion.  My further suggestion 
is to have instructions right after those links stating how to get 
started with Red/System and also Red.  A simple step-by-step for 
beginners.

I obviously, work as a Windows debugger using most of the core Windows 
Debugging tools and Systems Internals so I could contribute along 
those lines until I get knowledge of RED.

The easiest way to get all the files is to use the download.r script:

No need, I'd like to get on with my work

I have that bookmarked, but haven't yet looked it over thoroughly. 
I noticed that the last time I tried to determine R3 syntax the effort 
generated a lot of bug tickets. The same would likely happen once 
I get a chance to go over Red syntax, and they may end up being a 
lot of the same bugs. Some syntax issues are an inevitible result 
of being in the same syntactic family, and not realy arbitrary when 
you consider the balance of the entire syntax.

Features like that need to be provided, not created by the user base. 
 There's no motivation for anyone to get involved if the feature 
set isn't complete.

http://lessons.runrev.com/spaces/lessons/buckets/809/lessons/12304-How-do-I-use-Unicode-in-Rev-

In "Using character chunk expressions with unicodeText" section:

    set the unicodeText of field 2 to the unicodeText of field 1


Wow...doesn't look like Livecode scales up very well. In Rebol/View:

    set-face field1 get-face field2

Kaj: you'll have refinement and paths support tonight for the runtime 
lexer. I will add some more interpreter tests tomorrow and prepare 
for a new release (0.3.2) this weekend focused on the addition of 
the interpreter.

Arnold: you'll get your new blog article in a couple of days. ;-)

Pekr: "That is understandable, but it almost feels like a push - 
either do it R3 way, or it is your bug :-)"


Not always. R3 isn't done yet either. Remember, we're still catching 
up with a 2-year backlog of pending design changes. Some of its design 
experiments have turned out to be bad ideas for reasons that weren't 
known at first, or in some cases discovered by Red. So sometimes 
R3 is the one that needs fixing, and much sooner because R3 is going 
to get to 3.0 long before Red's design is set.


There are real advantages for Red and R3 to declare that incompatibility 
in comparable situations should be considered a bug, especially then 
it comes to syntax, and sometimes when it comes to semantics (ie 
indexing). But I don't assume that either R3 or Red in in the right. 
More often these incompatibilities are a sign of things that haven't 
been fully thought through, and once they are it could be R3 or Red 
that needs fixing, or in some cases both.


But, in the scale of history, Red is much earlier on in its design 
process than R3 is. R3 is more towards the end, closer to release. 
So that means that any changes that might break the *core* semantics 
or syntax of user code need to be made very soon, before 3.0 comes 
out and sets the standard. Red can afford to make those changes later 
because it isn't anywhere near the point of standardization. So if 
there are design flaws in R3 that might be comparable to something 
that would affect Red, they need to be fixed earlier in R3 (not by 
the Red people unless they're into that). And it would be useful 
for Red if people would participate in the R3 design discussions 
for stuff that would affect Red too because Red would benefit from 
the discussions regardless of compatibility, and also benefit from 
being compatible with the results.

State of Red's PARSE: 


It's not on the roadmap because it's too low-level for the bird view 
(maybe I need to add it anyway?). Moreover, PARSE is not (for now) 
useful for the internal construction of Red/System and Red, so from 
that perspective, it's quite low-priority.


OTOH, it is quite simple to implement in Red/System, and users could 
see that as a sign of good progress, so I probably need to schedule 
it for a weekend to implement a R2-level PARSE (with a couple of 
features from R3's PARSE) and a few more days to test and debug it.


Also, Gabriele is interested in implementing a "compiled" PARSE version 
for Red, but unfortunately, Red has not yet all the features that 
Gab needs for it (mainly object! support). So, he's waiting on me 
to get Red ready first.


As currently, object! support is much more important to implement 
(for completing the context/binding model of Red and enabling ports) 
than PARSE, you might get Gab's version first. Also if it's fast 
enough, I wouldn't need to make a Red/System version then.


Last but not least, I don't agree with 100% of the changes/addition 
in PARSE for R3, so I would need to review R3 parse and make a "cleaned-up" 
version for Red. Also, Topaz has some interesting improvements on 
PARSE what I might want to include in Red's version too, so that 
needs a bit of preliminary review work.


So, as you can see, it's hard to give you a precise timeframe, I 
guess we would have a first version of it during Q2 2013.

Some of the new operations were added to reduce bugs by having clean 
implementations of things that PARSE users frequently need to do 
but usually get wrong, such as CHANGE, INSERT, REMOVE, IF, THEN, 
AND, NOT, QUOTE and DO. The modification ops are the ones that lead 
to the most frequent R2 parse errors.

BrianH: compiled dialect is what Gabriele wants to implement. It 
should indeed be efficient in Red. About the review, I think we should 
get it organized somehow, I know that Gabriele has also some words 
to say about it too. But this can wait for a few more weeks.

implementations of things that PARSE users frequently need to do 
but usually get wrong, such as CHANGE, INSERT, REMOVE, IF, THEN, 
AND, NOT, QUOTE and DO

 this is where I *must* disagree. THEN seems to be infrequent, CHANGE, 
 INSERT and REMOVE are not frequent either according to my experiences 
 (nor they should be frequent), DO is a typical "one user feature".

I agree about THEN though (that was a Carl thing), and to some extent 
DO. For DO in particular I have seen people request help doing stuff 
like that frequently enough, but they either give up or are capable 
enough to not get it wrong.

I get here:

    red>> print x * 5

    *** Script error: action 13 not defined for type: 2

It does, you don't get the functionality and fixes in master, and 
it's hard to install

I've almost implemented file! completly this morning, but am now 
trying to get the multi-line strings literals recognized by both 
compiler and runtime lexers. A bit harder that it seems at first 
look, but should be ready for tonight anyway.

I just added char! to LOAD. It doesn't support the whole set of escaped 
sequences, only the most used once. Also, the molding of codepoints 
< 32 is not escaped yet, so you'll get strange results on screen.


I'm working on improving MOLD on string! and char!, to better support 
escaping of special characters and correct usage of {} braces when 
required.

I probably won't have time to finish file! before going to sleep, 
so you'll get it tomorrow.

Better specify it clearly each time you announce comparative performances, 
else people will generalize it and get a wrong picture of the real 
performance ratios. 


Fibonacci basically tests the efficiency of the function calls. A 
test with a bigger loop could be interesting. For example, you can 
take the %demo.red script and strip all screen outputs, add a LOOP 
around the main code and  you'll should see much bigger differences.

Kaj, what matters in such benchmark is not the usefulness of the 
resulting data, it is how the test stresses the language implementation. 
From that perspective, Fibonacci just tests the efficiency of nested 
calls, nothing else, no series manipulation, no memory allocation, 
very limited math, very limited control flow, ... The demo code will 
stress more parts of the implementation, hence giving you a more 
accurate picture (closer to what user will experience with their 
own scripts).


If you take the language Shootout tests, each test is meant to stress 
a specific part of each language, giving a good (and quite fair) 
comparison for each category.


I think we should implement them in order to get a good picture of 
Red performances and how they evolve. Anyone interested in implementing 
them? http://dada.perl.it/shootout/