World: r4wp

Giuseppe: they might seem similar on the surface, but I can garantee 
you that you'll see and feel the difference when Red will be mature 
enough.

Giuseppe: you seem to not understand the difference between a interpreter 
and a compiler.

Yes I understand.

But I want to make the DEVIL ADVOCATE.

When RED will be mature. In which scenario should a developer choose 
it instead of REBOL3 ?

(And let me state again: I apreciate your commitment)

It is a question that must be answered. It is the core of your project, 
it is the motivation for your "customers".

GiuseppeC: Red/System is a language to build other languages using 
a similar syntax as REBOL, one of which is Red. R3 is based on C. 
There is no way for R3 to tap directly inline into C's performance, 
while Red will be able to. I think this is quite a feat that might 
make Red much more flexible than R3. You also get encapping right 
out of the box with the current compiler. I can't come up with an 
appropriate car analogy.

Henrik, PERFORMANCE. It is the first difference. Now the car can 
run faster.
Any other differences ?

Red/System also offers a nicely compact and clean toolchain, which 
R3 doesn't even focus on. As far as I know, not many people like 
the current C toolchains.

I am talking about RED and not RED/System.

Just to make it clear.

That means that we have total 100% control over how and where Red 
can build. We don't depend on the quality of the compiler for a platform.

I can see and huge difference between C and RED/System which give 
to the latter a great appeal to the developers.

I don't think you can talk Red without talking Red/System, because 
in the long run, you may be happy to have Red/System available instead 
of resorting to C for performance parts.

Henrik, yeas, I want RED/system, I feel this needing. It is easy, 
human compatible, it is nice. It makes the difference.

Ok, I am leaving, I have to go away.

Henrik speaks wise words. For the past decade, we've been occupied 
with maintaining the GNU C/C++ toolchain in Syllable. If it hadn't 
been so problematic, we could have spent that time developing the 
operating system itself, and the project might have been in a much 
better position now

To everyone: my questions are not meant to create problems. I work 
every day with customers and they always ask me "which is the difference 
between you and this other product/service".

So the difference between Red and R3 is between a car that takes 
you there, and a car that breaks down before reaching your destination

It's a fair question, but the answer depends on insight

I find myself less and less interested in REBOL, even open sourced

Well Guiseppe, you may have to think of a second hand car ;) 

You can drive with it, it can be the car you wanted but some details 
as its color and chairheating can differ from what you had in mind. 
It is up to you to buy it anyway. By buying second hand you can have 
a more powerful engine than buying a new car.

Remember that the REBOLution was proclaimed to create the next generation 
operating system. However, REBOL falls seriously short there, not 
having delivered an operating system and not running well on top 
of any other operating system

Red does solve the problems that need to be solved there

For what I have seen, Kaj, I can second that. I use REBOL to learn 
Red ;)

And the liberation from the C tool CHAIN Viva la Liberation!

:-)

It may be time to consider REBOL an idea, a good one and one that 
now needs to have its true wings in the form of Red.

it would be also possible to rewrite R3 in Red/System, but then R3 
would be similar to Red itself?

Doc tells me an interpreter would be simple to write in Red, so even 
there no need for R3

Does R3 need a console? It would be the interpreter made using Red.

you beat me Kaj!

Kaj - not sure it will be a console, but something like that, just 
not an interpreter, but more a JIT compiler?

Red will be a JIT compiler, but you could still write an interpreter 
on top of it. Might even be useful, for example for platforms that 
block JIT compilation

When the "Red Memory Manager" Doc will be released?

I posted in Sublime Text's forum in regard to the lexing needs that 
we might need for good Red support. The author hasn't answered yet, 
but maybe if others add to the thread, it'll keep it near the top 
and show there's interest in the idea. I suppose even if ST doesn't 
make its lexer pluggable, we could just make the built-in lexer do 
as little as possible by including no tmLanguage file for Red and 
delegating any syntax coloring/scope processing to a native library 
that's part of a Sublime Text package for the Red language. 

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=9870

I think Red's USP is, "the performance of C with the elegance of 
REBOL" ... which is attractive to many folks like myself who woundln't 
otherwise venture near a "compiled" language (given the usual ease 
of use trade-off).

Nenad, could you describe a little the structure that's built up 
by the lexer? Are you intending to (at some point) allow for some 
sort of AST-like (if this is not what's generated already) structure 
to be passed back in along with some way of describing the start/end 
of a modified region in order to reduce the parsing that would need 
to be done if the lexer was being called relatively frequently when 
editing a large source string?

Jerry: when I find time to write it. :-) Probably when I get back 
to memory manager code to add the few missing parts, like GC and 
allocation of big memory chunks, that should happen in the next weeks.

AdrianS: the output of the lexer is nested blocks of Red values, 
same as REBOL with its own lexer (LOAD). The AST is not stored anywhere, 
AST nodes are created and consumed on the fly during the compilation. 
So the closest thing to an AST you can get currently is the output 
of the lexer.


For the needs of a code editor, maybe you could just invoke it on 
the currently edited line (though you would need to deal with unmatched 
opening/closing delimiters). I haven't yet though how I will achieve 
it in Red IDE.

This is all far out of my league. Though I had the same feeling when 
I started working with computers many years ago :-) Keep up the good 
work!

It's not as complex as it sounds. Feel free to ask any question about 
it in Rebol School or in ~ChitChat if it's purely Red-oriented. Open 
source projects are an excellent way to share knowledge and I would 
be glad if Red project can help people (including myself) learn something 
new.

Doc and the others:

I hav had some considerations about the RED = REBOL issue and I will 
continue the discussion in the REBOL3 area.

I noticed doc-strings are not available yet for #import?

It's late to talk about merging. It's been 2 years, Red is getting 
mature very soon aspecially after the Red/System part is almost done. 
Don't make any distraction to slow it down. ... Besides, R3 is not 
open yet (where is the code?), Red and Doc are all we got now. Doc's 
got the whole plan for Red, which is a good plan. We donate for that 
plan, not for a merge plan. The latest blog article in Red-lang.org 
made me realize that we might have a complete and mature Red in one 
year.

Jerry: that sounds like a realistic deadline to reach 1.0 release, 
as long as I can keep working full time on Red in 2013. Though, Red 
should be fully usable in a couple of months, all features would 
not be there, it won't run at full speed, but it will be enough to 
be able to build almost any app.

Kaj: the compiler should accept them from #import too...looking into 
it....

Nope, no support has been added for doc-strings in #import, but it 
obviously should be supported. I will add it tomorrow.

Thanks. Will have to wait in my bindings for the next release, though

Doc, how about Red becoming the Rebcode part of R3? IMO that would 
be a nice addition.