World: r3wp

vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
30)

 => we will need a better way to handle such arrays when interfacing 
 with third-party libs...

Yes

I found the same info that Windows system libraries use stdcall, 
but that MSVC defaults to cdecl. I had been compiling the binding 
with stdcall, and both work. I standardised on cdecl and retained 
the comment for the moment being

I'm getting this:

Compiling /users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
...
*** Compilation Error: invalid struct syntax: [pointer!]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds
*** at:  [struct [
        content [pointer!]
        flags [byte!]

What's the new syntax for a pointer field in a struct?

pointer! [integer!]

Actually it isn't a new syntax, it's just that the compiler wasn't 
checking it deep enough until now.

Shouldn't an actual pointer! type be possible?

What you're saying, that's a pointer to an integer, right? But I 
need a pointer to a bigger memory area here

Pointer! alone is equivalent to an integer, it just represent an 
address, but can't be dereferenced.

If you are just passing the pointer! reference but never dereferencing 
it, you could just use integer! instead (or c-string!).

Yes, it's just to reserve the space for a pointer that's used by 
0MQ, but not by Red

I'm trying to use pointer! as much as possible instead of integer! 
because it makes clear that we're talking about an address size, 
not what happens to be the compiler's integer size

Agreed. You could also use aliased types for that: 
    handle!: alias integer!
or
    void-ptr!: alias integer!


Aliased typed are not yet fully supported nor tested, but it should 
work fine in your case.

Sorry, I meant:
    handle!: alias pointer! [integer!]
or
    void-ptr!: alias pointer! [integer!]

You might want to avoid using handle! for these, as it is the best 
candidate for the opaque-pointer-sized-value type in Red proper, 
that all of Red/System's pointer! types would appear to be when they 
leak into Red code.

Well, isn't that exactly the reason to use it?

I mean, don't use the word 'handle! as an alias because it will likely 
be a built-in datatype in Red, and in all Red/System functions and 
datatypes exported to Red.

But it would be exactly what you want, wouldn't it?

handle!: alias integer!

would override the built-in meaning of handle!. All code that uses 
that word would need to be changed when Red comes out.

Keep in mind that there is no bounds-checking for Red/System's pointer 
type, and Red/System has typecasting (rather than conversion). Neither 
of those would be allowed in Red itself because of typesafety issues. 
Red/System will be like the unsafe code of C#.

That would be just a little code, and it's obvious that you have 
to develop your programs to stay in sync with a language that's in 
alpha status

Yup. But it's also good to warn them of planned developments once 
they're definitely planned, and this one is pretty well established.

Exactly, so that's the reason to start using the handle! type now

No, that's a good reason to *add the handle! type to Red/System* 
now, as a preemptively reserved word. Not a reason to use the word 
handle! to refer to a completely different thing.

It still means that I start writing "handle!" in my code now

Perhaps it could be a name for a non-dereferenceable void pointer 
type, since that's the closest C equivalent.

Basically, Red's handle! type would be the same as R3's handle! type. 
Opaque value that is pointer sized, but can't be used as a pointer 
without typecasting, and no arithmetic possible. No conversions to 
other datatypes either in typesafe code.

That's in Red. Red/System is a different context

Yes, but Red/System's main purpose is to do things with Red data, 
so it needs to have access to Red's types, even if its own literal 
types are different. So Red/System needs to have a handle! type, 
even though Red/System code would need to typecast values of that 
type to something else in order to be able to do anything with them.

I don't see why it couldn't be the same type

Alias types are user-defined. The handle! type would be system-intrinsic.

Yes, a temporary difference in declaration, because as of now, there 
is no handle! type to declare

As long as the type is defined in the core runtime code, rather than 
in user code, there is no difference.

Exactly

And since it isn't defined in the runtime now, I have to write it 
myself until that time

The main thing is that it needs to be defined as *non-dereferenceable* 
and *no pointer arithmetic allowed*, so if Red/System's equivalent 
of the void pointer is so restricted, that will do. If dereferencing 
or pointer arithmetic is allowed on Red/System's void pointer type, 
that needs to be fixed asap.

Why? That would be the behaviour in Red. Red/System's task is to 
actually be able to do something with a pointer

Unless you want to make Red a true capabllities language, but you 
are opposed to that concept

In a strongly typed language, which even Red/System is, dereferencing 
a pointer means getting a value back that is of a known type; pointer 
arithmetic means adding in increments of the size of that type. A 
void pointer references nothing, and that nothing has no size. You 
must be required to typecast to another pointer type explicitly if 
you want to dereference the pointer, or to know how much to increment 
or decrement it.

The difference between Red and Red/System is that such typecasts 
are possible in Red/System.

If Red/System truely is to be strongly typed, there needs to be more 
than just pointer! [integer!]. The issue I'm currently having is 
exactly that there is no matching declaration for what I need

Right, there need to be pointers to other types. And support for 
more types, for that matter.

I'm not under a strong impression that this is planned. So currently, 
I need to treat Red/System as weakly typed

It is not currently planned *by Doc* to have Red/System be a complete 
language, since he only needs it to access a few system libraries 
and implement the Red runtime. He's said that others are welcome 
to contribute the necessary changes to make Red/System a more complete 
language.

If you want to use Red/System as-is to do more advanced stuff than 
that, then go ahead and break the rules. Or better yet, add the features 
you're missing.

I understand the burdens of future programs, but I've written a program 
right now that I have to keep working

In other words, the rules you're talking about don't exist

Still, I would welcome Red/System becoming strictly strongly typed