World: r3wp

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?

I think they both require the same amount of storage space (ignoring 
possible padding).

Ah, no, they don't.

Wait, doesn't the STRUCT function take a parameter for the initial 
value?

none: I think Kaj has already defined it as null in his 0MQ wrapper. 
:-) So, I could add it in the common runtime file, it costs nothing 
(which is the least for none). :-)