World: r3wp

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.

We'll probably still want to cater to the vast majority of C interfaces 
which just uses platform/compiler defaults.

Plus, struct references will be used to convert data to and from 
binary data read from files and network protocols, and those also 
need precise definitions.

I'd use a different and far more powerful dialect for that.

Right, we need settable defaults that can match the local C standard 
or whatever it is that sets the standard locally (JNI perhaps).

But if you don't have a way to specify the padding and maybe alignment, 
you won't be able to interface with C code that sets that stuff too.

One dialect for conveniently interfacing with C ("structs"), a different 
dialect ("records"?) for 100% precise control over bit layouts. Plus 
a way to convert between the two.

The former quite possibly replicating some C quirks, probably a few 
of the most important ones, as needed.

C structs are what I'm talking about, particularly ones declared 
with the pragmas. The quirks can go in the settable defaults, including 
things like the size of certain datatypes that have ill-specified 
types in the C standard.

You are a little spoiled on Unix-like platforms, Andreas. On Windows 
there is no standard C compiler; there are a bunch of competing ones 
instead. Each has its own quirks and defaults. Since Red is not itself 
written in C, you can't just go with the quirks of the same compiler 
it is written in. And different libraries are compiled by different 
people with different compilers. If you want to interface with them, 
you have to be specific.

I'm unfortunately more aware of this than I would like to be :)

It's worse for me usually, since most of the libraries I need to 
interface with are written in languages other than C (C++, Delphi, 
.NET, Java), or have to match precise binary interoperability standards 
(COM, etc.). Simple C compatibility would not work for me at all, 
and this has also been the case with R2's library interface. Fortunately 
the database access has made my SDK license worth it :)

Thanks guys for the insights and propositions. I found it a bit difficult 
to follow in realtime, I'm not sure that AltME is the best tool for 
such conversations. Maybe we should give a try to the Red web forum 
next time: http://groups.google.com/group/red-lang?