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

World: r3wp

[Red] Red language group

Dockimbel
7-Jun-2011
[1926x2]
NOT is evaluated the same as other functions. As BrianH says, only 
two levels of evaluation, same rules as in REBOL. In the specification, 
it is listed under the "Infix Operators" category, I should either 
move it out or add some notes.
Operators in Red are both infix and prefix

: right, same as in REBOL, so, same limitation for using an operator 
in prefix mode.
Kaj
7-Jun-2011
[1928]
It would be good to make that clear in the documentation. NOT now 
seems to be an operator like in other languages, where inversion 
usually associates strongly
jocko
9-Jun-2011
[1929]
I observe a strange behaviour at the compilation of this code
#import [
                "user32.dll" stdcall [
                               OemToChar: "OemToCharA" [

                                               in                            [c-string!] 

                                               out                        [c-string!] 
                                               return: [integer!]
                                               ]
                ]] 
error message :

Compiling tests/readConsole.reds ...
** User Error: Invalid hex literal: Char: "OemToCharA" [
            in      [c-string!

** Near: make error! reform ["Invalid hex literal:" copy/part s 40]

It seems to be linked to the names used here. Is it a parsing problem 
?
Dockimbel
9-Jun-2011
[1930]
Yes, it is a preprocessor issue, I will fix it asap.
jocko
9-Jun-2011
[1931]
thanks, Doc
Dockimbel
9-Jun-2011
[1932]
Jocko: 

- ticket opened for your issue: https://github.com/dockimbel/Red/issues/89

- fix has been pushed in commit: https://github.com/dockimbel/Red/commit/5f5e7d6e1c7f03e1f2dbcae61a05044550f0bed1
jocko
9-Jun-2011
[1933]
thanks, works fine
Kaj
9-Jun-2011
[1934x2]
If I have an #import function returning an integer! but I define 
it as logic! will that work properly, doing an implicit as-logic 
on the return value?
That would make some convenience wrappers unnecessary
jocko
10-Jun-2011
[1936]
Same error with CharToOem ...
Dockimbel
10-Jun-2011
[1937x3]
Jocko: sorry to hear that, I will improve the fix I did yesterday 
right now.
Kaj: you can do an explicit casting, if is allowed by this matrix: 
http://static.red-lang.org/red-system-specs.html#section-4.7
Jocko: fixed by last commit: https://github.com/dockimbel/Red/commit/7b069cfefdf869cedfac9d2e1685c222320aaafd
Kaj
10-Jun-2011
[1940]
I'm currently doing explicit castings, but that requires a wrapper 
function, which takes up space in the source and in every binary. 
So I was wondering if it would be a good idea to obsolete some of 
those wrappers
Dockimbel
10-Jun-2011
[1941x3]
So you are asking to make the type system even weaker, I thought 
you were a proponent of strong typing ;-)
Could you solve is with defines? Something like: #define foo [as 
logic! _foo]
is => it
Kaj
10-Jun-2011
[1944x3]
I don't think it would make typing weaker, because it is about the 
definition of external functions, that you have to believe on the 
blue eyes of the #import spec writer, anyway
C functions don't have a logic! type, so I would argue that defining 
one in a return type if you know the C function returns a compatible 
value actually makes typing stronger
A define would still generate code, so it wouldn't lead to reduction 
of source or binary size
Dockimbel
10-Jun-2011
[1947x2]
The integer! -> logic! is not free, it implies generating extra code 
for converting properly (see the type matrix). So the define won't 
generate any more overhead than needed.
I just did a test using as-logic to convert an integer! returned 
by an imported function, it seems that the compiler is not generating 
the conversion code in such case...I need to investigate that issue 
deeper.
Kaj
10-Jun-2011
[1949x2]
I'm fine with the extra code generated. It would be like inlining 
just one as-logic operation, and only generated when needed
The alternative is always going through the wrapper function, which 
is slower, and only for the as-logic, so this strikes me as a case 
where you would want to inline. The #import spec can be a nice syntax 
touch to signal that
Dockimbel
10-Jun-2011
[1951x5]
Pushed a fix for the missing conversion code on type casting function 
call return value.
Right, as-logic will inline some conversion code only when required 
by the conversion rules from the type casting matrix.
I am considering your request for an implicit casting for imported 
functions using a return: [logic!] declaration. I could add it, by 
forcing a type conversion if the function is imported, but if the 
function already returns the right value (0 | 1), it will have to 
pay an extra cost for a useless conversion and no way to avoid it.
Like in the case where users would link to their own external libs, 
where return values are prepared specifically for Red/System.
So manually controlling the casting seems like a better option.
Kaj
10-Jun-2011
[1956x2]
But then you have the overhead of the wrapper function
How about having return: [logic!] mean that 0 | 1 is returned, so 
no conversion is necessary?
Dockimbel
10-Jun-2011
[1958]
Wrapper: not necessarily if you use a define as shown above.
Kaj
10-Jun-2011
[1959]
The problem with that is that you have to do it for every function. 
It's more work, in a different place than the #import. It feels like 
a hack, whereas return: [logic!] lets the compiler know the exact 
type
Dockimbel
10-Jun-2011
[1960]
Well, that is the default behaviour already. You just have to be 
sure that the imported function is respecting that convention strictly.
Kaj
10-Jun-2011
[1961]
Besides, the #define would still generate the extra code, wouldn't 
it? There's currently no way to specify that no conversion is necessary 
for a return value
Dockimbel
10-Jun-2011
[1962]
Just don't use any type casting and no conversion code will be added.
Kaj
10-Jun-2011
[1963]
But will integer! than be handled as logic! in expressions?
Dockimbel
10-Jun-2011
[1964]
Certainly not, but we were talking about an imported function with 
a return: [logic!] declaration?
Kaj
10-Jun-2011
[1965x2]
Well, that was my original question, whether that already works as 
I would like :-)
So it can only be used when strictly 0 and 1 are returned in integer! 
format?
Dockimbel
10-Jun-2011
[1967]
Exactly.
Kaj
10-Jun-2011
[1968]
OK, thanks
Dockimbel
10-Jun-2011
[1969]
If you function return 0 for false and a positive number for true, 
it needs a runtime conversion.
Kaj
10-Jun-2011
[1970x2]
Fair enough
Any plans to implement automatic inlining in the future?
Dockimbel
10-Jun-2011
[1972x3]
Yes, but probably as part of a future optimizing compiler version.
So, probably when Red/System will be rewritten in Red.
I would also adopt a fastcall convention as default for Red/System 
function calls.
Kaj
10-Jun-2011
[1975]
Awaiting that, I'll refrain from the #define solution, then