World: r3wp

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?

avoid putting in if 0 checks all over the place
: That's what I was concerned about on the implementation side.


just go by condition codes instead, especially for inlined control 
flow code.
 That's already the case.

Array! and pointer! literals: I'm not satisfied myself with that, 
but that's the best I could come up with, so far. If you have better 
propositions, I'll be glad to adopt them.

Out of curiosity, why did you use &[ ] for those typed serialized 
values instead of #[ ] as in REBOL?

Aside from the & character, those are basically the same thing as 
the serialized syntax of REBOL.

For a simple reason: you can't use LOAD on not-REBOL datatypes names: 
#[pointer! 0] triggers a LOAD error.

I've played with ALIAS to try to workaround that, but it wasn't a 
good idea.

So it's basically & [ ], not a single syntactic structure. Ok.

So, I finally chose to use the & character (already used in C and 
other languages to mean "address of") with a datatype description 
for pointer! literal form.

Right, & word and a block!.

Since we use AND and OR instead of & and |, there's no conflict with 
making & be a prefix builtin operator. Cool.

Exactly.

What do you think about dropping pointer! in favor of struct!, as 
struct! could do the same job? (See my last blog post)

I have mixed feelings about it. Pointer arithmetic is considered 
appropriate in a systems programming language if you want to make 
sure from the beginning that it is unverifiable. If you want a safer 
language, C++-style references are better. But the main problem with 
this is the same problem with R2's struct! type: It's too C-centric. 
Many languages other than C support actually passing structures into 
functions and returning structures, not just passing and returning 
pointers (or references) to them. Because of this I found the R2 
FFI model to be unusable to interface with the code that I really 
needed to call, which was as a matter of course never written in 
C.

Max: p[20]:  0 and  p[13 string!]: "hello"


These are not valid syntax in REBOL nor will be in Red. You're stretching 
the syntax a bit too far with putting a colon at the end of a block!.

I want to have a real structure type, not having a structure be equivalent 
to a reference to a structure.

This is something that could be added at Red level (in the core set 
of datatypes or as a user-defined type). Red/System will have to 
interface with C libraries mainly, that's why I took the C-like way 
to manage structs as references instead of values.

I noticed that in one of your structure examples one of the fields 
had a type of pointer! without a qualifying type. Are you supporting 
this?

It's a typo I guess.

the thing is that red/system isn't actually a semantic equivalent 
to REBOL its hard to keep an exact REBOL syntax equivalent.

Typo fixed.

Max: that's the hard part of Red/System design.

btw, in your spec I noted that you have the comma identified as part 
of the syntax, that's invalid in REBOL.

You need to look at it as if you were building a dialect for REBOL 
that compiles to native code, but trying to keep the syntax and semantics 
as clean and familiar (from the REBOL user POV) as possible (trying 
to avoid C pitfalls while retaining its possibilities).

Comma: probably an error.

though it would be a welcome separator (ignored like a whitespace).

would make a lot of data readable by rebol directly which cannot 
be currently used.

The C-like way is to manage structs as structs. The reference limitation 
is only for function parameters and return types. Other languages 
(which also have libraries that we might want to access) support 
passing structs as parameters, and for internal use we definitely 
want to support in-memory structs.


Still, we have objects for in-memory structures, so we're good there. 
If you want to see a structure as a reference type, it could just 
be a metaphor for binary conversions. In that case, dropping the 
pointer type and just using struct! for that would work pretty well, 
and make dereferencing the pointer a simple matter of syntax, rather 
than a operator or built-in function.

Commas are valid in REBOL. They're used as decimal points, European-style.

And a leading comma is like + or - or . as a number prefix.

Max: that would be an issue as in french, for example, you write 
decimals with a comma. Also, I thinks it's too valuable to use in 
some literals to make it transparent for some rare use-cases.

well, use of comma as an alternative for decimals is a waste of a 
character.   commas have given me headaches in many apps where I 
had to build a string parser from scratch instead of just loading 
the string.

anyhow...  didn't know it was usable for decimals in REBOL .

>> 1,2
== 1.2

I have made a much more thorough set of parse rules for words in 
R3, including replicating the exact behavior of errors triggerd (except 
the Near field). See http://issue.cc/r3/1302for details.