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

World: r3wp

[Red] Red language group

Kaj
18-Jun-2011
[2081]
I know, but I #define it as handle! like we talked about before, 
but there's now no way to define handle! in such a way that it works 
everywhere
Dockimbel
18-Jun-2011
[2082]
Have you tried with defining it as integer!?
Kaj
18-Jun-2011
[2083]
I once did, but I doubt it will now compensate for c-string! and 
NULL
Dockimbel
18-Jun-2011
[2084]
Integer! is conceptually the closest type to handle!.
Kaj
18-Jun-2011
[2085]
Yes, so why not define NULL and byte-ptr! as integer?
Dockimbel
18-Jun-2011
[2086]
About NULL, please read the ticket on github I have posted above. 
NULL will be changed.
Kaj
18-Jun-2011
[2087x2]
Sure, but why not fix this inconvenience right now?
I don't care what handle! is, just that there are three incompatible 
definitions
Dockimbel
18-Jun-2011
[2089]
Because I currently work on another ticket.
Kaj
18-Jun-2011
[2090x2]
It's just changing the two lines I cited above
I don't mean right now right now, I mean before making NULL polymorphic
Dockimbel
18-Jun-2011
[2092]
The NULL changes will be done this weekend, you won't have to wait 
too long.
Kaj
18-Jun-2011
[2093]
That still leaves the incompatibility between byte-ptr! and the documentation
Dockimbel
18-Jun-2011
[2094]
byte-ptr! as integer?: certainly not, byte-ptr! as it names implies 
is a byte! pointer, so semantically different than just integer!.
Kaj
18-Jun-2011
[2095]
But you're saying all the time that a void pointer is conceptually 
closest to an integer?
Dockimbel
18-Jun-2011
[2096x2]
Right.
You should erase the "void pointer" expression from your mind, it 
is corrupting your vision. :-)
Kaj
18-Jun-2011
[2098x2]
Again, I don't care much what it is (although I wouldn't expect ALLOCATE 
to return a c-string!), just that the definitions are compatible, 
so you don't have to insert confusing typecasts everywhere
I'm just following what you have written in the manual about pointers
Dockimbel
18-Jun-2011
[2100]
the definitions are compatible
: which ones?
Kaj
18-Jun-2011
[2101]
NULL, byte-ptr! and the manual use three type incompatible definitions. 
I must compare and pass these types
Dockimbel
18-Jun-2011
[2102]
NULL and documentation will be fixed during this weekend.
Kaj
18-Jun-2011
[2103]
So will they be compatible with byte-ptr! thereafter?
Dockimbel
18-Jun-2011
[2104x2]
NULL should work with any kind of pointer/struct or be removed.
I haven't decided yet on the right solution, but you can safely use 
ALLOCATE as it is defined right now, that won't be changed.
Kaj
18-Jun-2011
[2106]
Not really, because casts are needed on every use of ALLOCATE and 
FREE
Dockimbel
18-Jun-2011
[2107x2]
That would be the case whatever type you would put in the return 
definition of ALLOCATE?
As you can allocate memory space for various datatypes.
Kaj
18-Jun-2011
[2109]
No, because there's one exception: the type that ALLOCATE and FREE 
choose to use
Dockimbel
18-Jun-2011
[2110]
You've lost me...what type are you talking about?
Kaj
18-Jun-2011
[2111]
They currently use c-string! I'm not sure that's the clearest one. 
It's unintuitive to me, as if the type returned is very specific 
and comes with a zero byte at the end
Dockimbel
18-Jun-2011
[2112]
That is why I have not put c-string! but byte-ptr!.
Kaj
18-Jun-2011
[2113]
I know, but that gets lost during compilation. What the compiler 
complains about is that you have to cast to and from c-string!
Dockimbel
18-Jun-2011
[2114x2]
Do I really need to add a new [pointer! [byte!]] to the compiler 
just to make this error message looks nicer?
(I mean adding a new datatype in the compiler).
Kaj
18-Jun-2011
[2116]
I think that would be very useful, but that's the more fundamental 
pointer discussion. I'm now just concerned about making casts the 
least confusing
Dockimbel
18-Jun-2011
[2117x2]
I pretty sure that some ppl would complain that [pointer! [byte!]] 
is exactly the same as c-string!...;-)
I don't get what is the issue with casting (expect the error message)?
Kaj
18-Jun-2011
[2119]
Sure, but I mean, we had two definitions of a generic pointer: integer! 
or pointer! [integer!]. Why confuse it with c-string! now?
Dockimbel
18-Jun-2011
[2120x7]
expect => except
Well, I have already answered that question above. I am sorry if 
that change breaks existing code. Once again, the C void pointer 
is a very confusing concept that should not be used outside of C 
language. If you refer to a C void pointer without any context, it 
is just a memory address, so integer! (or handle!) would be the closest 
corresponding concept. If you refer to a C function returning a void 
pointer like malloc(), the closest transposition in Red/System would 
be ALLOCATE returning a byte! pointer.
Malloc() allocates a memory region that granularity is by default 
a byte (until you cast is to something else).
So, in summary, there is no 1 to 1 transposition of the C void pointer 
concept in Red/System, it is 1 to 2 (or more), depending on the context.
If you would write a C function such as: 

void *bar() { return((void *)&foo);)


where foo would be another function. If I had to make a binding to 
this function from Red, I would use integer! (or preferably the handle! 
macro) to define the return value.
Six months ago, I wanted to introduce an address! type to be the 
equivalent of C void pointer. It would have worked as an integer!. 
But as it would have been only used to in C binding definitions, 
I thought it would be a waste to have a first-class datatype just 
for that, when integer!, pointer! [...], or a macro could do the 
same job.
If [pointer! [byte!]] could do the job and make C coders happy, I 
will add it to Red/System.
Kaj
18-Jun-2011
[2127x4]
I'm not concerned with all that here. Let me make this very concrete. 
In runtime/common.reds, changing
#define byte-ptr!	c-string!
to
#define byte-ptr!	pointer [integer!]