World: r3wp

Kaj, in any case, you can just replace #{037B} by #{037F} in IA-32.r 
at line 20: 

    fpu-flags: to integer! #{037B}

Thanks, but I'd rather not do that

For non-variadic C functions, Red/System's compiler will promote 
float32! to float! automatically.

Does that mean that external functions that use single precision 
can't be bound?

Have the docs been republished yet? The #enum link points to #include

Sorry, forgot to update the docs online.

Docs updated.

Thanks

Kaj: you can pass single precision values to C functions, but C automatically 
converts them to double. C always passes single precision floats 
as double precision, and converts them before pushing them on stack.

but C automatically converts them to double
 => "but C always expects double"

That seems odd to me. What's the point of single precision, then? 
It would be slower than double precision

#enum <name>! [
   <label> +
   | <label>: + <value>
]

Doesn't that syntax spec preclude the mixing of value labels and 
non-value labels?

Are enumeration names pseudo-types equivalent to integer!? I guess 
so, but the documentation doesn't say

See http://en.wikipedia.org/wiki/Type_conversion#Type_promotion


C and C++ perform such promotion for objects of boolean, character, 
wide character, enumeration, and short integer types which are promoted 
to int, and for objects of type float, which are promoted to double.

Single precision purpose: I guess the only advantage is smaller storage 
size. Some Intel FPU operations are even slower in single precision 
than double precision.

Doesn't that syntax spec preclude the mixing of value labels and 
non-value labels?


Yes it does. I should rewrite the syntax definition to be more accurate 
and more readable...any suggestion?

I think that single precision is used mostly on GPUs as you can have 
up to 2 single float operations per clock.

Interesting, thanks for the explanations

I'm not sure what grammar syntax you use and what exactly #enum supports, 
but something like this?

#enum <name>! [
   (<label>
   | <label>: + <value>) +
]

I would like a less formal syntax description if possible. I would 
like to remove all the `+`.

I've added Mandelbrot drawing floating point examples to the C library 
binding, for Red/System and seven other languages, to compare them

when I compile following line, I got "*** Compilation Error: redeclaration 
of enumerator c from colors"
#enum [a b c]
print-wide [a b c]

#enum colors [a b c]

That's a name clash

I see, so it should be corrected on the web page, Red/System Language 
Specification.

Its given as example for #enum directive, but it cannot be compiled.

#enum [a: 1 b c d: e: 10]   ;<--- missing <name>
print-wide [a b c d e]

#enum colors [A B C D E]   ;<--- redeclaration
print-wide [A E]

I even get "*** Compilation Error: unknown directive enum" when testing 
it. :-)


I was wondering if I haven't introduced some regressions when merging 
the float-partial branch, but all the enum tests are running fine...

in first example enum <name> is missing and  it gives "unknown directive 
enum" error.

in the tests there is no missing name I think.

needs to be fixed on the web page only.

You're right, I'm not used to enums yet. :-)

and if #enum colors [a b c]  declares a,b,c; then why we need a <name>?

shouldn't it be
#enum colors [a b c]
print-wide [colors/a colors/b colors/c]

it is very difficult to declare an enum without a name-clash, if 
<name> is not used.

No, the name should be colors! and the purpose was to use is as a 
pseudo-type when declaring an argument or a return value.

Redeclaration of c: it seems to be an internal issue, `c` should 
not be declared in global context.

where it should be declared then? in the example on the web site:
#enum colors [red blue green yellow]
a: red

colors
 used nowhere, so "red" is global. No?

How do we know that "red" is an enumaration from "colors", if we 
don't use "a: colors/red" or somethink similar?

Enumerations as namespace: why not...needs some deeper analysis to 
see if its consistency with the rest of the semantic rules and if 
the implementation does not disturb existing compiler code too much.

red
 is global => yes.

in many other language we should give the name of the enumaration 
to get a value from it.

without using this way, it is almost impossible to use enumarations 
without a clash.

That's the way C works, the enumerations in Red/System is a direct 
transposition, works the same way.

so no chance to compile something like:
#enum colors [red blue] ;in file 1
#enum tests [red green] ;in file 2

compiler fails when including both file.

Currently, no.

Ok. So we at least need to fix the examples on the web page.

The reason enumerations were added by Oldes was just to simplify 
the writing of some bindings which heavily rely on enumerations.

Even in C we specify where we take the value, 
enum color {red,green};
color col = red;  <-- col declared as a color.
red is not defined as global.