World: r3wp

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

Nope, struct has no initialiser.

STRUCT: it is a keyword, not a function. The memory space it takes 
is zero-filled.

I figured as much, since the type system would need this to be a 
keyword because the type returned is derived from the argument.

Hmm, that may be a stupid question, but: why not simply use a POINTER 
keyword similar to STRUCT for pointer declaration.

I was thinking that none could be a none! type, and then autoconvert 
to the particular reference type on assignment. Or it could be of 
type handle! in Red/System, with a predefined 0 value.

Andreas: could work and it  would be more consistent with struct. 
The other option is using & both for pointer and struct references.

Well, you don't really need a POINTER keyword if pointers are just 
syntactic sugar for struct references. Then & could be the keyword 
for both.

If you are happy with allowing address arithmetic on struct references, 
that's fine.

That sounds good. I need to take some time tomorrow to think about 
all that and see if there's no drawback hiding somewhere.

But I think struct padding requirements will kill address arithmetic 
on struct references for the general case.

Padding should be explicit in the struct declaration syntax, or default 
to no padding.

Padding is platform-specific.