World: r3wp

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

Among the changes, 'null is now a global variable defined as a null 
pointer.

So, #define is the way to go to rename existing types and ALIAS is 
reserved for struct! only (it allows to circular references that 
couldn't be done using macros).

Kaj: "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" 
Could you tell me what is your need precisely?

it allows to circular references
 => it allows circular references

I need a pointer to a struct of which only 0MQ knows the structure. 
So any pointer will do, unless you want to make Red/System strongly 
typed

dockIbel one cool thing thqt could help promoting RED would be to 
do a openSUZE minimal distro using their tool that gives a linux 
ready to use out of the box with all needed to code or enhance red

I know it zas made for Illumination software creator and was a good 
enightenment for it

plus ISC opensuze distro was custom distro of the year which spread 
even more the word

could be a good way in a middle term to have tools + OS etc in a 
single CD

No need, it already exists

You're right, I should add a mention about it on red-lang.org.

Kaj: I pushed a few fixes and changes on ALIAS support, it now behaves 
strictly as described in the specification. For the 0MQ binding, 
you need to replace [struct! message!] occurences with [message!] 
to make it compilable with the new version.

Including your previous changes, I figure?

Yes.

Processed your changes, and indeed it builds again

Have a new batch of issues, but will research more first

In the spec in 4.5.5, shouldn't the child structs gift/first and 
gift/second be created individually (and assigned to the struct pointers 
in gift) before their members can be assigned?

At the end of the last example in 4.6.2, shouldn't

a/count: p/count

be

a/count: p/value

?

It would also be good to make it clear that the integer! pointed 
to by p needs to be separately allocated (presumably by foobar and 
GetPointer)

4.5.5: yes, you're right, the example is missing gift/first and gift/second 
proper initialization.

4.6.2: right too, it is a typo.

At the end of 4.6.5,

;-- writes 123 (4 bytes) at 40000008h

should be

;-- writes 123 (4 bytes) at 40000004h

(I hope)

Yes, it's 40000004h as the index is one-based.

By the way, what minimum CPU is your emitter targeting?

You mean the current IA32 implementation or more generally?

Red/System requires at least a 32-bit CPU.

The current IA32 implementation should work on a 386 I guess (but 
would need to check for some of the addressing mode used, they might 
not be all available on the 386). A safe minimum CPU should be the 
Pentium.

OK. So maybe it would conflict with the minimum 486 target of Syllable 
Server. Syllable Desktop targets 586

Not that I'm testing Server on 486, and the utility is dubious. But 
Red will be suitable for embedded systems, so there may be a good 
niche in 486 systems-on-a-chip

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 !).