World: r3wp

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.

Max: if you need to make commas LOAD-transparent in a string!, it 
is as easy as: replace/all string "," " "

It still doesn't handle the full set of Unicode, just ASCII, but 
I can reverse the charsets to be complemented opposites and it will 
handle those too.

C's struct! type is a roundabout way of specifying memory layout. 
A more direct way for specifying memory layout would certainly be 
nice, but if you want to interface with C-like code a lot, you'll 
want memory layout (storage) specifiers that allow you to mimic C 
(ABI) semantics.

Brian: I've bookmarked that ticket already. Will use your rules for 
defining Red's lexical analyzer.

I.e. while you can get rid of pointer! and just use &[integer!], 
that is fine. But if you specify integer! as always being a 32-bit 
integer, you lose out in hiding cross-platform quirks.

I'm hoing to expand them to be a full R3 code version of TRANSCODE, 
in a module.

You could just say that all references are structs, and that the 
pointer! type is a shortcut for making a struct! with a single field 
named value.

Andreas: that's the idea. All Red/System features are here to serve 
either the interfacing with OS and third-party libs (mostly C libs) 
or to serve the upper layer (Red) needs.

Though I would change this:
    p: &[pointer! [string!] 0]             ;-- char **p = 0
to this:
    p: &[&[string!] 0]                         ;-- char **p = 0

You can get rid of the pointer! name altogether and still keep the 
syntactic shortcut.

Then I'd keep the pointer! type as a specifier for the target platforms 
"pointer type".

Or you could call it handle! like R3 does.

The pointer! default value could always be 0 ,so that value could 
be removed from literals.

Then, real structure variables could be specified with #[struct! 
...] instead of reference types that are specified as & [ ].

#[struct! ...] can't work if I use non-REBOL datatype names...That's 
why I used 'struct as keyword to workaround that.

But you might be able to get by with only structure references and 
not have real structure variables. Then structs would be conversion 
metaphors.

The main advantage to real struct! variables rather than just reference 
types is bounds checking. Can you build in bounds checking into your 
reference use, or are you just hoping for the best? Since C doesn't 
have encoded bounds, struct! references used for C interop would 
have to follo the hope-for-the-best model.

Andreas, the target platform's pointer type points to something. 
Unless you know at least the size of that something, let alone its 
type, it is unsafe to use such a pointer. It is best to pretend that 
an untyped pointer is not a pointer at all, just a pointer-sized 
opaque value like R3's handle!. You can then explicitly convert that 
value to a typed reference in order to be able to use it as a pointer.

That is all fine and well, but won't help you interfacing with C 
code.

(Or other system ABI-compliant code, for that matter.)

Brian: I can't see how I could make Red/System safe while been able 
to fully interface with C code?