r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

Dockimbel
29-Mar-2011
[766]
Andreas: that's the idea. All Red/System features are here to serve 
either the interfacing with OS and third-party libs (mostly C libs) 
or to serve the upper layer (Red) needs.
BrianH
29-Mar-2011
[767]
Though I would change this:
    p: &[pointer! [string!] 0]             ;-- char **p = 0
to this:
    p: &[&[string!] 0]                         ;-- char **p = 0

You can get rid of the pointer! name altogether and still keep the 
syntactic shortcut.
Andreas
29-Mar-2011
[768]
Then I'd keep the pointer! type as a specifier for the target platforms 
"pointer type".
BrianH
29-Mar-2011
[769]
Or you could call it handle! like R3 does.
Dockimbel
29-Mar-2011
[770]
The pointer! default value could always be 0 ,so that value could 
be removed from literals.
BrianH
29-Mar-2011
[771]
Then, real structure variables could be specified with #[struct! 
...] instead of reference types that are specified as & [ ].
Dockimbel
29-Mar-2011
[772]
#[struct! ...] can't work if I use non-REBOL datatype names...That's 
why I used 'struct as keyword to workaround that.
BrianH
29-Mar-2011
[773x3]
But you might be able to get by with only structure references and 
not have real structure variables. Then structs would be conversion 
metaphors.
The main advantage to real struct! variables rather than just reference 
types is bounds checking. Can you build in bounds checking into your 
reference use, or are you just hoping for the best? Since C doesn't 
have encoded bounds, struct! references used for C interop would 
have to follo the hope-for-the-best model.
Andreas, the target platform's pointer type points to something. 
Unless you know at least the size of that something, let alone its 
type, it is unsafe to use such a pointer. It is best to pretend that 
an untyped pointer is not a pointer at all, just a pointer-sized 
opaque value like R3's handle!. You can then explicitly convert that 
value to a typed reference in order to be able to use it as a pointer.
Andreas
29-Mar-2011
[776x2]
That is all fine and well, but won't help you interfacing with C 
code.
(Or other system ABI-compliant code, for that matter.)
Dockimbel
29-Mar-2011
[778]
Brian: I can't see how I could make Red/System safe while been able 
to fully interface with C code?
Andreas
29-Mar-2011
[779x2]
Or in other words: "pointer-sized opaque value" -- that's exactly 
what I'd use the pointer! type for.
With the focus on pointer-sized, not on opaque. The opaqueness is 
a separate issue, but you _need_ a specifier for pointer-sized values.
BrianH
29-Mar-2011
[781x2]
Sure it will, Andreas. The explicit conversion is just there to catch 
bugs in your code. The handle! type is just to interface C code that 
takes a void pointer. All other pointers would be struct! references. 
And this code:
    &[integer! 0]
would just be a syntactic sugar shourcut for this:
    &[struct! [value [integer!]] #{00000000}]
or something like that.
And then all C int* values would just correspond to that type.
Dockimbel
29-Mar-2011
[783]
Brian: is there any documentation about R3's handle! type? This page 
is empty: http://www.rebol.com/r3/docs/datatypes/handle.html
Andreas
29-Mar-2011
[784]
It's a value you can do nothing with :)
Maxim
29-Mar-2011
[785]
btw, when allocating arrays, the use of /value should not be required. 
 just like in C and REBOL's use of path notation, it should adapt 
to what is being pathed. 

using: 
p: &[array! [20 integer!] 0]

should be used with 
p/4: 123 

in fact:

 p/4/value: 123 

would be used for:
p: &[array! [20  &[integer!]] 0]
BrianH
29-Mar-2011
[786x3]
So the opaque pointer-to-? type would be called handle! for compatibility, 
and typed pointers would be handled by struct! references. And you 
can do inline struct! values like this:
    #[struct! [value [integer!]] [0]]

which is the serialized syntax for a struct! in R2, on R2 platforms 
that support structs.
Doc, if you match the serialized syntax for R2 structs then R2 can 
load your values to compile them.
Then you can have real structs as well as struct references.
Dockimbel
29-Mar-2011
[789x2]
Brian: that is what I was doing until I introduced the pointer! datatype. 
R2 chokes on pointer! in struct! specs.
Same goes for int8!, uint8!, ...
Andreas
29-Mar-2011
[791x2]
I think R2 will also choke on handle!.
(Didn't try, though.)
Dockimbel
29-Mar-2011
[793]
Right, same issue.
BrianH
29-Mar-2011
[794]
Yup. You would be limited in what types of structs you could declare 
as inline values in Red until you switch to your own loader. But 
you wouldn't be limited in what you can declare as struct! references.
Maxim
29-Mar-2011
[795]
AFAIK R2's struct!  can't properly represent many of the structs 
I've wanted to play around with.
Dockimbel
29-Mar-2011
[796]
Max: good point
Maxim
29-Mar-2011
[797]
I guess you where refering to the array comment above?  :-)
Dockimbel
29-Mar-2011
[798x3]
yup :-)
I've fixed the array! examples, thanks.
But I agree with you also about your last comment. Things like arrays 
are a PIA to interface with using R2's struct!.
Andreas
29-Mar-2011
[801]
Hmm, I maybe should've read the spec more carefully, but:
BrianH
29-Mar-2011
[802]
The & syntax would be for struct references and the # syntax for 
struct values. And if you initialize your struct reference with a 
integer it will be a pointer value, but if you initialize it with 
a block then an inline struct could be built and then referred to 
with the reference. So this:
    a: &[integer! 0]
would be the same as this:
    a: &[struct! [value [integer!]] [0]] 
or this:

    set a: &[struct! [value [integer!]]] & #[struct! [value [integer!]] 
    [0]]
Andreas
29-Mar-2011
[803x2]
Ah, ok, nevermind.
I wouldn't re-use the & syntax for array datatypes.
BrianH
29-Mar-2011
[805]
And you can use make struct! instead of #[struct! ] since the compiler 
can do the same thing in both cases, and then R2 wouldn't complain.
Dockimbel
29-Mar-2011
[806]
>> make struct! [a [pointer!]][0]
** Script Error: Invalid argument: pointer!
Andreas
29-Mar-2011
[807x2]
Referring to section 4.2, if `&[string! 0]` equals `char*`, what 
does string! equal?
I think string! should be char*, &[string!] should be char**, and 
&[pointer! [string!]] should be char***. But maybe I'm missing something 
:)
BrianH
29-Mar-2011
[809]
Not at the source level, Doc. Just because that won't work in R2 
doesn't mean it won't load.
>> load "make struct! [a [pointer!]][0]"
== [make struct! [a [pointer!]] [0]
]
Dockimbel
29-Mar-2011
[810x2]
Andreas: you're right, there's an issue on that line, char *p should 
match string!.
Brian: you're right, it has been a long day... :-)
BrianH
29-Mar-2011
[812x2]
It would be better if you could match the MAKE argument model of 
R3 rather than that of R2. Have MAKE take two parameters, not 2+.
That is a special case in R2 that makes everything difficult. It 
was a good change.
Dockimbel
29-Mar-2011
[814]
But, that solution would turn MAKE into a keyword, so I couldn't 
use it anymore for making a malloc( ) wrapper for example. It could 
work with some tweaks in the compiler, but I'm not sure such hack 
would be desirable.
BrianH
29-Mar-2011
[815]
No, the R2 model turns MAKE into a keyword. The R3 version can just 
be a function.