World: r3wp

Wouldn't it be good to be able to write pointer! [ ] instead of pointer! 
[integer!] for a void pointer? I cringe a bit every time I see it. 
(Spoiled by REBOL, I guess)

A pointer! [integer!} is not a void pointer, it's a pointer to an 
integer.

I cringe whenever I see a multi-part statementthat is supposed to 
be taken as one thing that isn't a function call or in a block; all 
of the pointer! [something] statements qualify. Why is the 'pointer! 
word there at all? In the places where types are allowed, wouldn't 
the block be enough? Or is pointer! not a type, but instead a one-parameter 
function that returns a type, that for some reason has a ! on the 
end of its name?

You mean having:
    foo: func [[integer!]][...]
instead of:
    foo: func [pointer! [integer!]][...] 
?

sorry, bad syntax

Yeah, that second one looks like it takes two parameters.

I mean if the first takes one.

So: 
   foo: func [a [[integer!]]][...]
instead of:
    foo: func [a [pointer! [integer!]]][...]
?

Yes, the second one looks like it takes void pointer or a pointer 
to an integer, the pointer! word referring to a void pointer.

Realizing that this is supposed to be one thing trips me up all the 
time.

Weirdly enough, if the ! was gone from that keyword for the typed 
pointers it wouldn't trip me up because it would look like the subsequent 
block is part of an expression. Then the pointer! word would refer 
to an untyped pointer (void pointer) on its own with no block needed, 
though I would prefer handle! instead for R3 compatibility, and to 
make it more visually distinct from pointer (without the !).

We already have similar construction for the struct! type...I really 
don't see why this one should be wrong...Pointer! is not a void pointer, 
simply because a pointer! needs to point on something. A C void pointer 
is just a memory address, so an integer! would work fine to represent 
it on all 32/64-bit platforms I can think of.

Brian: your mental representation of a function specification block 
is wrong, it is not made of REBOL expressions, but it is a separate 
dialect with its own rules. Pointer! is closer to those rules than 
pointer (with no ending !).

Darn, I didn't get around to summarizing that argument here about 
struct vs. pointer in the google group, so it looks like its conclusions 
were completely ignored.

Also, if this syntax makes you choke, you can just use: #define handle! 
integer!

So much for pointers just being a simplified syntax for a subset 
of the struct types.

You asked me to summarize the argument in a google group post, but 
I didn't. Sorry.

Well, it is a bit late now as Red/System implementation is reaching 
its end. I am trying to stick as close as possible to the REBOL syntax 
we are used to, if you have better propositions for the syntax, I 
am ready examine them, but I would like to finish on Red/System and 
start working on upper layers, unless you want me to polish Red/System 
for the next months and start working on Red 6 months later than 
I planned?

I would like also to remind you that Red/System will be re-implemented 
entirely in Red at some point, so we'll have a second chance to fix 
design and implementation issues/limitations if necessary.

It's not a problem.

The pointer! [...] syntax does make sense as a shortcut for struct! 
[value [...]] in function specs - that type equivalence was the important 
part of the earlier argument, not syntax issues. The only place that 
the syntax looks weird is in AS calls, where otherwise expression 
rules would apply. I'll look over the specs later this evening and 
see if there's anything really weird-looking.

You mean that you would prefer writing it without outer brackets 
for type casting (like: as pointer! [integer!] ...)?

(as proposed by meijeru on the ML)

No, I mean that pointer! [integer!] would be exactly the same type 
as struct! [value [integer!]] - type equivalence between pointer! 
and struct!. This would make the pointer! type a syntactic sugar 
shortcut for a subset of the struct! type. That is the semantic portion 
of what you wanted me to write down for you in a google groups post 
so you could refer to it when you were implementing that suggestion. 
There were also syntactic issues, but those don't matter as much.

This was long before meijeru got on the Red google group.

Right, I think I should add it as a note in the specification draft.

I've been busy lately so I haven't read the latest couple spec drafts. 
Must catch up and comment, quick before you finalize things.

I will push new specification changes and fixes tonight. I have added 
a type casting matrix for all possible type combinations. I am currently 
  implementing the missing cases.

Do you make a distinction between implicit and explicit type casting? 
Does Red/System have any implicit type casting at all yet?

Yes, it does an implicit type casting for math and bitwise operations 
on the second argument.

I have pushed the changes for the type casting matrix support (both 
in docs & implementation). I need to add proper tests to cover that 
tomorrow.

4.6.6 of the spec now says that the official type for a void pointer 
is integer! but this leads to type mismatches with null

Null is currently of type pointer! [integer!], I need to get it back 
inside the compiler to make it polymorphic. Just use 0 for integer! 
or handle! (if you've defined it) in the meantime.

I would like to introduce my second Red binding, for the standard 
C library:

http://red.esperconsultancy.nl/Red-C-library

So far I have bound 25 functions and written two higher level wrappers

I've used it to implement printing of integers in the examples for 
the 0MQ binding

Doc, feel free to use any of it that you need in Red

You can print integers in Red/System

Just include this - https://github.com/dockimbel/Red/blob/master/red-system/tests/quick-test/prin-int.reds

May not be clever but it prints integers.

I know, but this is a solid solution, and there are 26 more functions 
:-)

I've bound all memory management functions, most of the string processing 
functions and a few system interfacing functions

Looks good and will also act as a good example.

Thanks

Kaj, thanks for the contribution. I have planned to wrap some of 
the memory manipulation functions too as soon as I finish the work 
on aliasing and type casting.

Hats off to Kaj!
 - from Miejeru on the Red Google Group

Thanks :-)

Red can load library functions with different calling conventions, 
but which convention does the emitter generate for its own functions? 
Cdecl?

Internal functions: stdcall