World: r3wp

Right, same issue.

Yup. You would be limited in what types of structs you could declare 
as inline values in Red until you switch to your own loader. But 
you wouldn't be limited in what you can declare as struct! references.

AFAIK R2's struct!  can't properly represent many of the structs 
I've wanted to play around with.

Max: good point

I guess you where refering to the array comment above?  :-)

yup :-)

I've fixed the array! examples, thanks.

But I agree with you also about your last comment. Things like arrays 
are a PIA to interface with using R2's struct!.

Hmm, I maybe should've read the spec more carefully, but:

The & syntax would be for struct references and the # syntax for 
struct values. And if you initialize your struct reference with a 
integer it will be a pointer value, but if you initialize it with 
a block then an inline struct could be built and then referred to 
with the reference. So this:
    a: &[integer! 0]
would be the same as this:
    a: &[struct! [value [integer!]] [0]] 
or this:

    set a: &[struct! [value [integer!]]] & #[struct! [value [integer!]] 
    [0]]

Ah, ok, nevermind.

I wouldn't re-use the & syntax for array datatypes.

And you can use make struct! instead of #[struct! ] since the compiler 
can do the same thing in both cases, and then R2 wouldn't complain.

>> make struct! [a [pointer!]][0]
** Script Error: Invalid argument: pointer!

Referring to section 4.2, if `&[string! 0]` equals `char*`, what 
does string! equal?

I think string! should be char*, &[string!] should be char**, and 
&[pointer! [string!]] should be char***. But maybe I'm missing something 
:)

Not at the source level, Doc. Just because that won't work in R2 
doesn't mean it won't load.
>> load "make struct! [a [pointer!]][0]"
== [make struct! [a [pointer!]] [0]
]

Andreas: you're right, there's an issue on that line, char *p should 
match string!.

Brian: you're right, it has been a long day... :-)

It would be better if you could match the MAKE argument model of 
R3 rather than that of R2. Have MAKE take two parameters, not 2+.

That is a special case in R2 that makes everything difficult. It 
was a good change.

But, that solution would turn MAKE into a keyword, so I couldn't 
use it anymore for making a malloc( ) wrapper for example. It could 
work with some tweaks in the compiler, but I'm not sure such hack 
would be desirable.

No, the R2 model turns MAKE into a keyword. The R3 version can just 
be a function.

Make: I agree, fixed arity is a cleaner way.

Make: I was thinking in Red/System context. I would need to turn 
MAKE into a keyword in order to spot literal struct! values.

You would want to do that anyways for other literal values, though 
the function use would be a fallback in case the spec is an expression.

What's the problem with making MAKE a keyword? You don't have function 
values in Red/System, and you don't want it redefined without the 
compiler knowing about it. Speaking of which, typed function references 
with overloaded &[function! [...]] syntax?

Some C libraries take function pointers as arguments to their APIs.

Unless you don't want to handle the callback problem yet.

I guess I could do the fallback on expressions in order to use it 
as a function too.

Functions: yes I was thinking about reusing the & symbol for getting 
function references.

And if MAKE is a keyword, depending on the expression it could fallback 
to calls to different functions.

Callback: not now, it is too early.

considering callbacks are just pointers, its not that big a deal 
to provide the capabilities...  all you need is a way to get the 
address of a function rather than call call it, and you're good to 
go.  this could be achieved easily with get-word notation...

Wait, is
    a: &[integer! 0]
equivalent to:
    a: &[struct! [value [integer!]] 0]  ; a has a value of null
or this:

    a: &[struct! [value [integer!]] [0]]  ; a points to an integer with 
    a value of 0
I would prefer the former. Then this code:
    a: &[integer! [0]]

might be equal to the latter, with the integer being allocated as 
a local variable on the stack.

Or you could insist on this instead:
    a: 0
    b: & a

Callbacks: the first step is to be able to output a DLL ;-)

Are there conceptual problems (exports and such) or is it just a 
matter of writing out the files properly?

Just implementation, no conceptual issues for outputting DLLs.

I'd have the &[] syntax to always mean "pointer to", i.e. a reference 
type.
And as far as I understand the current spec,
  a: &[integer! 0]

means "a pointer to an integer!, with the pointee's address being 
0"

is
   a: &[integer! 0]
equivalent to:
    a: &[struct! [value [integer!]] 
0]  ; a has a value of null

Yes, it is.

It would therefore be equivalent to
a: &[struct! [value [integer!]] 0]

if structs don't require any storage space (except padding) on their 
own.

I prefer to think of it as syntaxtic sugar, but basically yes. And 
structs should be padded explicitly somehow, with a sensible default.

syntaxtic - syntactic

At the moment, it really is no syntactic sugar, I fear :)

Only relatively :(

Wait, there's a mistake in my example in the blog: 
    p: &[integer! 0]
is not equivalent to :
    p: struct [value [integer!]]


The struct value takes an additional storage space for the integer 
value while the pointer doesn't. :-(

Adding this default 0 value was really just adding confusion.

I jumped to the pointer dropping option too fast.

Are you going to allow the word none as an equivalent to the null 
pointer value?