World: r3wp

A few features are waiting for extra support in Red/System

Doc, love the painting you used for the  'What is the state of Rebol 
World?'  I've forgotten who the artist is do you know?

I know it from Asterix :-)

The examples in 10.1 and 10.2 use hex numbers in lowercase

Am I right when I assume that #include does not prevent against double 
inclusion of the same file?

Is NOT evaluated left to right? It seems to have lower priority

#include was changed to only include a file once a little while ago. 
There was a comment to that effect in the commit notes.

Cool, thanks

If Red follows REBOL's evaluation levels, NOT would have lower priority 
than all operators. Two levels: Operators, and everything else.

It would actually make my current code case nicer, but I need to 
be sure it's intended

Does it mean NOT is handled as a function? It's listed as an operator

Operators are infix. Prefix is functions. But it might be implemented 
as a special case builtin, which would make it what other languages 
call prefix operators.

Operators in Red are both infix and prefix

The REBOL manual also fails to note the fundamental difference between 
NOT and the other logical functions/operators

Mchean: the second painting I have used is "The Raft of the Medusa" 
from the french painter Theodore Gericault: http://en.wikipedia.org/wiki/The_Raft_of_the_Medusa

Hex lowercased: thanks for reporting, fixing that for next spec release.

#include keeps an internal list of already included files.

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.

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

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 
?

Yes, it is a preprocessor issue, I will fix it asap.

thanks, Doc

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

thanks, works fine

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

Same error with CharToOem ...

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

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

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

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

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.

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

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.

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?

Wrapper: not necessarily if you use a define as shown above.