World: r3wp

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.

Right. And language-specific and library-specific on any given platform. 
That is why it needs to have a good way to specify it.

wouldn't the arithmetic, just use the padding as part of the size?

That's why C compilers have pragmas for padding.

C is the target here.

For C and a given platform (and a given compiler, for some weird 
corner cases), default alignment/padding behaviour is specified.

Right. And since that changes from platform to platform and compiler 
to compiler we need a way to match those differences, with declarations 
or options or pragmas, same as the C compilers do.

The important issue is that the defaults match, if we want to have 
any.

Otherwise we can just drop the whole attempt at easier integration 
with C and go with a much more sensible storage layout dialect (think 
e.g. Erlang bitstrings).

Another important issue is that the defaults be settable on a per-platform 
or per-app basis, and that the behavior of Red/System is explicitly 
defined in a cross-platform way. We don't want to repeat the mistakes 
of C just because we're interfacing with C.

A lot of the stuff we have to integrate with will have C interfaces, 
but those interfaces will have struct layouts in them that were declared 
with precision for binary compatibility, using the pragmas and stuff 
that C was retrofitted with to allow such precision. We need those 
kinds of abilities from the beginning, or we'll have to retrofit 
it on later just like C did.