World: r4wp

0%... prefix will clash with percent! datatype literal form.

The two last (0b... and 0h) do not read easily IMHO, especially if 
lowercases are allowed.

Anyway, having a prefix rather than a suffix is a possible option.

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

I tried a simple FOR loop, but no result and the compiler is quiet.

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.

lacking

The source code should be easily parse-able, so the list of functions, 
native, actions, ops could be extracted and pretty-printed as a web 
page. IIRC, someone tried to make such script but I didn't see any 
result yet.

New features added today worth mentioning:


- comparison operators (=, ==, <>, <, <=, >=, >) support extended 
to all datatypes.

- FIND action added (supports block! only for now, /match not implemented, 
/only always on)

Excellent news Doc.

Jerry wanted to publish ongoing feature stats

Yes I wanted to give it a try for the doc scripts. But parse is not 
my expertise, and at the moment I am short in time as I can make 
extra hours at work. So everybody step in please and publish your 
baby-doc-scripts so we can all contribute little bits.

Working to fix that COBOL code for 21-12-2012 to prevent the end 
of the world, eh? ;-)

About the case-sensitivity,

What about to convert all the words into lowercase in compile time? 
Does it lead some unicode problems? What if a word is in Chinese, 
is there lower/upper cases in Chinese?

No case sensitivity in chinese as there is no case

The issue is to keep them separate, instead of merging them into 
lowercase; but Doc has fixed it so far

For compiled code does it really matter? I thought it would only 
matter for words-as-data, and that compilation of case-insensitive 
code would make most words go away. For words-as-data, having some 
duplicate data when appropriate should be OK.

Are you going to have case-sensitive objects, or just case-preserving?

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.

Are you going to have case-sensitive objects, or just case-preserving?


Are you referring to words defined in the object's context? Probably 
just case-preserving.

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.

This is all old Rebol discussions, but Red would have similar issues 
with proposing such options because it was a matter of syntax.

Back to an older topic, hex syntax. If you had 16#abcdabcd translate 
to an integer!, it wouldn't have to be considered to be a conflict 
with #abcdabcd being an issue! value. It's just like {abcdabcd}, 
#{abcdabcd} and #abcdabcd are different now. There would be no reason 
to keep the hex syntax once the value is loaded, it could just be 
a regular integer. You could even keep the issue! type as a word 
type with some extra series-like operations supported, the way tuple! 
supports series-like operations without being a series.

I don't see any advantages in having case-sensitive objects (but 
I see potential issues allowing that). Have I missed something?

Hex: your proposition is acceptable, but it makes hex literals writing 
still a bit more verbose than needed. We should be able to come up 
with a better solution that leads to just one additional character 
in order to write and identify hex literals (hence my # suffix proposition, 
with a base-16 default value).

(For comparison again, sorry) In R3, objects are in many ways like 
the tables in Lua, used for data purposes as well as for contexts, 
underlying several other datatypes or operations as well. Most contexts 
are declared using these other datatypes or functions that wrap objects; 
raw objects are more often used as data structures than as contexts. 
It might make sense to support case-sensitive objects as data structures. 
Nonetheless, I wasn't the one making the suggestion, and I'd have 
to do a bit of research to dig up who was requesting this.

Most people would prefer case-preserving behavior though, despite 
how difficult that is for multi-language Unicode words.

I will answer in Language group.

FIND on string! implemented (only tested with no refinements).

Red is making progress fast :-)

Jerry: yes, it is. I just hope, that some I/O and later parse comes 
in next 2 months, to be really usefull in real life :-)

SELECT full support implemented for all series datatypes (including 
path access syntactic sugar).

Wow! You are making great progress Doc!

Go Doc Go!

Doc: "FIX: now FIND/match will return the tail of the match. " - 
aren't /match and /tail two distinctive refinements in REBOL's find? 
Why implicit /tail here?

ah, different thing, REBOL returns tail for match too, at least according 
to help string ...

Thanks Gregg! More to come...;-)

COPY on any-block! series implemented, /part and /deep supported 
(/types has not been implemented yet).

Never used /types before. There are so many refinements that I don't 
notice their existance.

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

Stay on target.

More than ever. ;-)

Hopefully we will see some synergies with the two projects.

I just had a very short look on R3 code yesterday's night, what striked 
me the most at first look is how both R3 and Red are struggling (in 
different ways) to avoid writing C code as much as possible. :-)

in what way is R3 struggling to write C code? Isn't it written purely 
in C?

It seems that is uses some REBOL templates to generate some additional 
C code during the building process, like this one:

https://github.com/rebol/r3/blob/master/src/boot/types.r

r3 / src / tools section is great :) I especially like make-make.r

R3's source also avoids direct C code by doing a lot of the work 
in macros. With the macros, the C source of a native doesn't look 
that much different than mezzanine code.

I noticed some similarities too in actions

Doc, as R3 got released on 12.12.2012, you should prepare some release 
or nice Red surprise for 21.12.2012, to be on pair :-)

Pekr, something like "The end of World and Red"?(no offense,  just 
a  joke Doc and John) :-)

Actually old stuff will die off - Mayans thought about the date as 
of the new fresh era, new oportunities, so quite the opposite :-)