World: r3wp

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

If and when that happens, I'll update my programs to be compliant, 
as I'm doing now

Well, it can't become strictly strongly typed, as a certain amount 
of type breakage is the whole point of its existence. You can't be 
strictly strongly typed if you have typecasting, pointer arithmetic, 
literal pointer values, or the ability to call C code. Red/System 
is supposed to be strongly typed with those rule breakers, in order 
to shield Red itself from those features.

Ehm, yes, that's what I've been saying all the time

Doc, defining handle! with alias doesn't work:

*** Compilation Error: invalid struct syntax: [handle!]

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

#define doesn't work, either:

** Script Error: Cannot use path on none! value
** Where: check-arguments-type
** Near: if all [
    not empty? spec: entry/2/4 
    block? spec/1
] [
    spec: next spec
] 
foreach

You wanted to know if the appointed error locations are correct. 
That seems to be alright, and the error for a struct is nicely descriptive, 
but an error for a function definition is rather unspecific:

*** Compilation Error: invalid definition for function send: [
    socket [pointer!] 
    data [pointer!] 
    size [integer!] 
    flags [integer!] 
    return: [logic!]
]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds 
*** at:  [func [
        socket [pointer!]

Oh wait. I have to use a block for #define, and then it works. But 
not ALIAS

And the error output for a function starts at the offending parameter, 
so that's actually pretty good, but it's not obvious

Here's a message that's not very clear:

*** Compilation Error: type mismatch 
*** expected: [pointer!] , found: [integer!]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds 
*** at:  [0 as-message message data]

I can't compare pointers to zero any more. Presumably, these are 
the arguments to the zero? function, but that information is lost

As a nitpick, there's an excess space in the message, before the 
comma

It seems that NULL is defined as integer! 0

So it seems that there is no way anymore to pass a null pointer to 
a function or to compare a pointer to null

null-p: as [pointer! [integer!]] 0

does that work?

I tried AS POINTER!

The only syntax I can get to compile is as pointer! [integer!] 0

null-ptr: pointer [integer!]
null-ptr/value: 0

should probably work as well

but `as pointer! [integer!] 0` is fine, if it works. the spec needs 
a fix so that the examples match the syntax spec, though.

Wouldn't that set the pointed to integer?

indeed, sorry for the confusion

Are imports type checked yet?

I can't get past the null comparisons, but I've checked my other 
fixes in to Fossil

Are imports type checked yet?
 Yes (but untested yet).

Thanks for all your feedback, it is really helpful. I will review 
every issue you've raised today.

Thanks. The 0MQ binding is a nice test case

I was a bit confused yesterday about ALIAS usage, due to this ticket: 
https://github.com/dockimbel/Red/issues/39.I jumped on fixing it 
too fast without first checking the specification, so I mistakenly 
extended ALIAS beyond its original purpose (which is just for aliasing 
struct! declarations, as described in section 4.5.5 of the specification).

I just pushed a new commit that reverts back some of the changes 
I did for aliased types yesterday, and fixes the compiler errors 
reported by Kaj.

I have uploaded a patched version of the 0MQ binding here: http://static.red-lang.org/tmp/red-0mq-fixes.zip