World: r3wp

Thanks Doc, that reads much better

Well, you have to think a little bit if Red is the same as those 
when it comes to searching. Perl is actually unique since pearl is 
the spelling of the oyster product. When it comes to Python, I can 
tell you that in typical English language use, the frequency of the 
word python will be relatively low, so you won't really pollute search 
results for the language which has a relatively large use in the 
IT community. Ruby is somewhat similar in that you won't find too 
many uses of the singular word ruby used by the general population 
- at least not to outweigh its language name frequency. When it comes 
to Red, I can guarantee you that red is quite a common word.

Redd?

well..... if you search red language in google, you already have 
the 3rd entry and several hits on the first results page, so I  guess 
it not that big a deal  :-)

sure, that's what I said above, you need to use "red language" - 
the thing is that "language" needs to be part of the query and I'm 
guessing that there will be lots of pages where this word will not 
be included. I just think that if you are going to be creating a 
new language, uniqueness in naming is only a plus and now would be 
the time to determine that rather than after its use is widespread

really it's not like there is a shortage of unique names out there 
- the only problem is that usually everyone has an opinion as to 
what's a good name - too many points of view

I think that the language name alone is not the typical query that 
someone would do. Here's two examples:


- Tiobe index relies on "<language> programming" as its search query 
to mesure the popularity of a programming language (see http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm)


- For Cheyenne web server (not a language, but uses a common name), 
people coming to the web site with only "cheyenne" as a search keyword 
are very few. A vast majority use "cheyenne server" or "cheyenne 
web" or "cheyenne rebol". Anyway, after been online for a few months/years, 
Cheyenne's web site appeared on first page if you search for that 
word only (while there's really a *lot* of others resources not related 
to this web server).


There's also another point to consider. If the target name is not 
strongly associated with an existing brand or a popular product, 
you'll see a lot of unrelated results on first page (that's the case 
for "Red"). So, AFAIU page ranking algorithm, once Red language will 
spread larger, I'm ready to bet that the cross-reference links of 
Red-related site (and back-references to Red's home site) will push 
it rapidly on the first page, or even in the top 3 list.

Anyway, I'm not against switching to a better (unique) name, but 
it needs really to fill my criteria:
- short
- sounds ok in english
- doesn't sound bad in french
- have a meaning related to the language
- if possible, not a backronym (they are usually bad)

- has .org / .com / .net free (it's ok if adding "-lang" is needed 
for that)
- I need to like it (or at least be able to get accustomed to it)

The jewel names could have been a good place to pick a programming 
language name, but last time I've checked all the good&short ones 
have been taken already.

(Gabriele took the last good one ;-))

zen

 was a good name that Carl once said he would have been willing to 
 rebrand REBOL to.

but I really like Red.  :-)

Zen would have been a good choice too for my language. IIRC, when 
I checked that a few months ago, it was taken already. Anyway, same 
lack of uniqueness as Red.

Stay with the name, Doc :-)

You could use ch'an ... that preceded zen :)

Ch'an Buddhism spread to Japan where it became known as Zen

I like Red. It's a strong, simple name with emotional connotations 
that isn't in current use for baffling unknown reasons. It's the 
same reason that Project (Red) chose it.

I have to say I'm not a fan of the something in 14.7 of the system 
specs: "Support 0 and 1 as valid boolean results". That is a bad 
practice, and putting it into Red/System might lead to it leaking 
into Red. Just because it's C level doesn't mean it needs to repeat 
C's mistakes. It's better to stick to the REBOL-like, Lisp-like truth 
values.

Well, it's just an option, as mentioned in my last blog entry, another 
one is to make boolean first class type.

I also would like variable declarations to infer type based on first 
(static) assignment.... much more usable.

That would be better, Doc.

Maxim, that is what he has proposed for the top level variables. 
It might work for locals as well though.

Another C mistake that shouldn't be emulated is in 14.5. Don't call 
your 8-bit integer "char!", as it doesn't work with multibyte characters. 
Use "uint8!" or "byte!" instead.

yes, byte! is better choice.

Thank you for the light version of the docs Doc. :-)

Call the boolean type uint1! and be done with it. For a systems programming 
language, 0/1 as valid boolean results makes eminent sense.

It's funny, I was about to thank you for the dark version :)

Brian: it might be too high-level for Red/System. I need to have 
a fine-grained control on memory accesses. A variable-size datatype 
would get in the way. But I admit I didn't consider that option, 
I would need to think about it deeper to see if it could be an advantage.

byte! (and uint8!) is certainly better than char!.

Hehe, I knew I would make everybody happy that way ;-)

exactly why is using 0 = false 1 = true bad?

uint8! is the more accurate, but a bit too cryptic. Byte! sounds 
nice.

0/1 as boolean makes sense with (possibly implicit) conversion to 
a boolean type, but 0/1 are not how conditional expressions are treated 
at the system level - those are handled with condition codes. If 
you don't have an explicit boolean type that is not an integer, you 
can end up with the if (a = b) problem all over again, especially 
once you allow chained assignments. Don't repeat C's mistakes.

If you want a "bit!" type for uint1, that would help too.

Max: variable type inference for functions locals should be easy 
to add. I'm against having an inference engine in Red/System, but 
if some rules are trivial to implement and give a significant advantage, 
I'll surely do it.

if (a = b) problem
: good point

I was also thinking that you might want to extend the integer qualification 
you added for hex notation to the other integer sizes, when they 
are implemented.  ex: 

33L
33s
33b

etc

Right, that's something to consider too. But I've often found such 
notation a bit hard to read and remember. Also to consider: hex syntax 
opens a hole in the "no digit as first character in words" rule. 
I hoped that I wouldn't have to break that rule again for other literals.

Doc, by multibyte chars I wasn't talking about variable-size, I was 
talking about fixed-size with Unicode support. A char! would have 
a single size, but that size would either be 1, 2 or 4 bytes depending 
on whether the base plarform supports ASCII, Unicode2 or full Unicode.

I think that such rule played well its role of barrier against typos 
in code for REBOL, even if it closes the door to some syntax combinaisons. 
So, I'm quite reluctant to break it further. A solution would need 
to be found for different sized integer literals.

Brian: right, but I'm not sure that Red/System needs to be Unicode-aware, 
at least not to implement UTF-8 Red's sources parsing.

I think that readable trumps consise in this case, Maxim. And for 
a compiled language, to-long 33, to-short 33 and to-byte 33 can be 
resolved at compile time with no overhead.

Unicode: it's an open question that needs experimenting further with 
Red/System. I'm not against to make char! a unicode codepoint type, 
if it helps coding at Red/System level.

Doc, if Red/System doesn't need to be Unicode-aware, you should replace 
the string! type in it with a binary! type and just have compiler-resolved 
string-to-binary conversions of string literals in the source. Have 
real strings only exist at the Red level.

That's the solution I was considering so far, but your point about 
Unicode makes me wonder if there's is not a better solution than 
the old C way.

All better solutions include byte! + binary! types :)

The old C way was based on legacy byte-size chars. It is better to 
be Unicode-aware from the start than it is to retrofit it.

Btw, you should probably specify that "printable characters" are 
bytes in the range 20h-79h

US ASCII only defines 128 characters.

Andreas, 79h is the DEL char, not printable :)