World: r3wp

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"

You are right.

I've modified the behaviour as you want, but we should wait what 
Doc will think about it. Now it works like:
#enum test! [a b]
f: func[/local b][
	b: 3
	?? b
]
f ;will print 3, not 1

f: func[][ b: 3 ] ;throws error as before

I think this is the correct behaviour, more compatible with REBOL 
as well.

I'm not sure about giving a warning if a local var. clashes with 
a global one (just for enums may be?)

warning's good in such a case imo, or your app will most probably 
behave incorrectly in the runtime anyway, no?

the problem is, that now it throws this error if C is used in enum:
*** Compilation Error: type mismatch on setting path: char/1
*** expected: [byte!]
*** found: [integer!]
*** in file: %runtime/utils.reds
*** in function: prin-byte
*** at line: 29
*** near: [
    char/1: c
    prin char
    c

I don't have time to check it now more deeply... maybe in the evening.

Oldes: I agree with your fix, the locally defined value should prevail 
over the enumeration value.

I've added the example of the proposed change to enum-test.reds (Enum-11).

And so what is expected behaviour for:
#enum test! [a b]
f: func[a [c-string]][]

In that case isn't a local to the function?