World: r3wp

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 :)

should be 7Fh, and 7Fh is the DEL char of course

But I'm referring to section 3, which currently uses 20h-FFh

Oh, right :)

Then printables go to 7Eh.

So use 20h-7Eh

Well, by default, Red/System could be transparent to UTF-8 (that's 
what will be used in Red for strings I/O), as is string! in R2. Will 
add char! as unicode codepoint to possible evolutions anyway.

Characters range: yes I need to change that, PeterAWood posted a 
note about it too: http://groups.google.com/group/red-lang/browse_thread/thread/99e14e44fbf69abf?hl=en

Red/System could be able to make values of all of Red's types, while 
not itself using all of its types in its own code. Red/System source 
could contain literals of Red's string! type, but its compiler will 
convert those literals to Red/System's binary! type. Then Red/System 
can make string! values explicitly by doing the conversions itself, 
or calling functions to do so. Make the Red/System language types 
a strict subset of the Red types, and don't pretend that you really 
support strings and chars in your language unless you have Unicode 
support built in. Then Red's built-in Unicode support would be written 
in Red/System code operating on binary! data :)

And then no code that calls C with char* types would pass in values 
of the string! type unless they have been converted to binary! first, 
implicitly by the compiler or explicitly by the code.

Good point. That was the plan. You've put it more clearly than I 
would.

I've kept the string!/char! analogy too long, so it almost confused 
me too. :-)

You might want to make it more explicit in the system design and 
docs that this is your approach, and add binary! and byte! as explicit 
types a lot sooner. Then you can do a tiny amount of type inference 
to at least have the compiler be smart enough to do the conversions 
when it can, so runtime conversions can be minimized.

Same with the bit!, bitset!, logic! group. Bits and bitsels are storage 
types, but logic values are what conditional expressions work with. 
This also has the benefit of letting the compiler avoid putting in 
if 0 checks all over the place and just go by condition codes instead, 
especially for inlined control flow code.

brian "I think that readable trumps consise in this case, Maxim."

well, right now, red is much less readable than C when types are 
involved. 


when I look at something like this (which is proposed as an extension 
to current type syntax): 
p: &[array! [20 integer!] 0]

I get nervous cause this is the anti-thesis of REBOL
why can't it be expressed like:

p[20]:  0  ; infered type


p[13 string!]: "hello"  ; explicit type, though usually superfluous

You don't want to overdo it of course, but the more info the compiler 
knows, the better code it can generate.

Maxim, I agree that the literal pointer syntax is bad. Do you have 
a better suggestion for the syntax of declaring explicit pointer 
variables, especially since you usually can't just write out the 
value of those variables as a literal number?