World: r4wp

And with string auto-scaling from 1 to 4 bytes per codepoints. ;-)

*codepoint

I will publish the new code tomorrow.

UCS1 to UCS4 scaling? Fixed-length internally?

Yes, Latin-1 / UCS-2 / UCS-4

Conversion for printing in UTF-16 done on-the-fly (no additional 
buffer needed)

Brian: you don't read Red's blog? :-) See http://www.red-lang.org/2012/09/plan-for-unicode-support.html

Been busy :(

Will you eventually be doing the same trick R3 does of keeping its 
symbols in UTF-8 format internally, for binary hashing? Of course 
you might be handling symbols completely differently...

The symbol being the string part of a word.

Yes, I currently keep an UTF-8 version in cache for each small string, 
but I'm not sure I will keep it.

I'm not using currently hashing for words, but indexing as lookups 
are done mostly during compilation.

I'm talking about eventually, when/if you get real runtime word types 
:)

Words dynamically created might need hashing though.

Right, it could be a good option.

I think that R3 stores symbols in something like a BTree.

Red stores them in a block! value currently, so probably the less 
efficient way...we'll see in the future how to optimize it the best 
way.

Maybe a Trie would be the best data structure for symbols (I have 
used them in other projects for fast short strings lookups).

One gotcha we ran into with R3: R3 uses aliases to handle case-insensitive 
word equality. We found that aliases were a good, safe use for that, 
but not safe or stable to use for anything else. Perhaps you might 
consider this for Red.

Maybe, I haven't decided yet how I will handle that.

I can think of using to-head and to-tail. My opinion is you should 
have a more descriptive name for your variable. So length-of-cityname 
instead of length. The length could be of anything and the variable 
could be reused. Besides native English speaking programmers have 
always faced the fact that their prime candidate for variable names 
were taken because they were a reserved word. Imho so is should stay 
length? and not be length-of though that last one saves me from pressing 
a shift-key.

Maybe it's too soon to think about optimizations, but what about 
function inlining?

(sorry that my question is out of topic... I was offline when I send 
it without noticing the unicode news:)

Optimizations are for Red/System v2 (the rewrite in Red). The compiler 
will have a different architecture much more suitable for optimizations 
(including function inlining).

Doc, how will the open sourcing of R3 have an impact on your Red 
work?  Will you be studying RT's code to see how everything was accomplished?

well, maybe depends upon the licence Carl selects? The other thing 
is - Doc might study some internals, but still he can't directly 
use C code, as Red is being written in Red/System, so C to Red/System 
rewrite would have to happen anyway ....

Of course, being able to understand Carl's R3 architecture might 
be REALLY inspirational, so I would not discount that option :-)

No changes for Red plans, I continue on the same path towards a complete 
v1.0.

Will you be studying RT's code to see how everything was accomplished?


Certainly not!! The GPL precludes me from looking at the code, the 
risk is too high to unconsciously write similar code and infringe 
the license. It is even worse than that, all Red contributions implementing 
a feature that exists in R3, will need to pass through a peer-reviewing 
process to determine if it is a derivative work of R3 or not. The 
reviewing persons would be able to look at R3 sources, but doing 
so, would not be able to contribute code to Red. So I strongly advise 
current and future Red contributors that wants to add REBOL features 
to Red from looking at R3 sources.

so C to Red/System rewrite would have to happen anyway ....

 No!! Porting GPL code to another language falls under derivate work 
 clause too. If it wasn't the case, it would be too easy to workaround 
 GPL terms by porting it from language A to B, then from B to A.


There is a reason why most big software companies prohibit their 
developers from looking at GPL source code.

Yes, that's how GPL can be bad to non-GPL world.

Besides that, GPL is great if you live in a GPL-only world.

Amen!

Your above post should be posted to the discussion forums ... the 
split of REBOL community might be apparent. As for me, I am staying 
with the active project, hence with Red ... Well, I am a coding lamer, 
so most probably I personally don't need to worry about eventually 
looking into R3 source code :-)

Feel free to re-publish my post everywhere you want. ;-)

(just fix the typos first ;-))

Well, I think that I will be a nice guy for quite some time, not 
trying to steal the happiness of guys out there :-)

So let me just say what I am thinking.. I wonder if R3 would be released 
already if you weren't making so much progress with Red..  I hope 
2 (or more) options will be able to bring even more people into Rebol 
family of languages. The time is about to be right. Python is getting 
sort of backlash (finally).

Well, R3 is not out yet, Carl did not say, which year he will release 
R3 sources on :-)

Before the Christmas, we might see extensive Red alpha, along with 
Android support ;-)

Janko: it can be a good or bad motivation for newcomers. Some might 
find it great to have the choice, other might be afraid by the fragmentation.

Because rebol/red are so different than anything else it might at 
the end help people learn about this coding mindset / convention, 
and then they have more choices. Sometimes lang choice is highly 
determined by runtime also (by my own exp).. in this case having 
many runtime options (red red/system rebol topaz) is a good thing.

anyway... Red is speeding with new dev last weeks, this is awesomest 
news for me.

I agree with you about the runtime choice. I wish Gabriele had more 
time to work on Topaz.

Janko: more "awesomenesses" to come in the next days/weeks. ;-)

It's ironic that we will have a GPL interpreter and a BSD compiler. 
It's much more logical to have a BSD interpreter and a GPL compiler...

The frontier between both architectures is blurry in modern language 
implementations. Red final compiler will be able to work both AOT 
and JIT, so BSD is the way to go.

I know, the irony is on the REBOL side

I'm on the Red team!

Red Unicode printing support extended to all Unix platforms:

http://static.red-lang.org/hello_unicode2.png

For those testing Unicode output on Windows, you need to change the 
default raster font of DOS console to Consolas (recommended) or Lucida. 
The default font is unable to print Unicode characters.

print "^(4F60)^(597D), ^(4E16)^(754C)!"  ; Chinese