World: r3wp

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

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.