World: r3wp

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.

Can you make a `red` global variable in C when `red` is already use 
as an enumeration value?

Specification document fixed.

Can you make a red global var..
 No, we cannot.
document fixed
, still we cannot compile the examples on Windows,
because of "redeclaration of c" in win32.reds file.

I mentioned it above, it needs a fix in the compiler and/or the runtime 
code.

*** Compilation Error: unknown directive enum
  = should I fix it to provide correct error message?

Endo - I'm sure that in a real life. you don't want to use #enum 
to define values like a, b, c, d as well as common names like red, 
blue etc.. Real life enum example naming is for example:
#enum DitherMethod! [
	  NoDitherMethod
	  RiemersmaDitherMethod
	  FloydSteinbergDitherMethod
]

Such an enumeration you can use in the import like:
#import [
	"CORE_RL_wand_.dll" cdecl [ 
		MagickRemapImage: "MagickRemapImage" [

   ;== Replaces the colors of an image with the closest color from a 
   reference image

   ;-- MagickBooleanType MagickRemapImage(MagickWand *wand,const MagickWand 
   *remap_wand,const DitherMethod method)
			wand	             [MagickWand!] ;the magick wand.
			remap_wand	[MagickWand!]

   method	[DitherMethod!] ;choose from these dither methods: NoDitherMethod, 
   RiemersmaDitherMethod, or FloydSteinbergDitherMethod.
			return:               [MagickBooleanType!]
		]
	]
]

I was also thinking about value test to prevent passing for example 
value 10 as a method in the MagickRemapImage, as it accepts only 
values 0, 1and 2. This is not implemented yet.

You are right.

The problem above, enumrated value clashes with a local variable 
in a function.

#enum test! [a b]
;...

f: func [a [integer!] /local b] []    ;<---- compile error, "redeclaration 
of b"

which could be problem in a big source.
...prevent passing...
 catch in compile time would be nice for sure.

if I compile just:
c = 0;

I get: *** Compilation Error: local variable c used before being 
initialized!

it's not bug related to enumerations.

(ech my error)

first i should use c: 0, and it compiles, so it's related to enums.

its another issue I think, in my example there is no c.

Example 1:
#enum test [a b]
b = 0   ;<--- global, redeclaration error, which is correct.

Example 2:
b = 0  ;global
f: func [/local b] [] ;<--- no error, correct

Example 3:
#enum test [a b]

f: func [/local b] [] ;<--- redeclaration error, incorrect! local 
b should not be clashed with enumarated-global b

oops sorry, I wrote "b = 0" should be "b: 0"