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

World: r3wp

[Red] Red language group

Dockimbel
19-Feb-2012
[5166]
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...
Endo
19-Feb-2012
[5167x3]
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.
Dockimbel
19-Feb-2012
[5170]
You're right, I'm not used to enums yet. :-)
Endo
19-Feb-2012
[5171x3]
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.
Dockimbel
19-Feb-2012
[5174x2]
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.
Endo
19-Feb-2012
[5176x2]
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?
Dockimbel
19-Feb-2012
[5178x2]
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.
Endo
19-Feb-2012
[5180]
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.
Dockimbel
19-Feb-2012
[5181]
That's the way C works, the enumerations in Red/System is a direct 
transposition, works the same way.
Endo
19-Feb-2012
[5182x2]
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.
Dockimbel
19-Feb-2012
[5184]
Currently, no.
Endo
19-Feb-2012
[5185]
Ok. So we at least need to fix the examples on the web page.
Dockimbel
19-Feb-2012
[5186]
The reason enumerations were added by Oldes was just to simplify 
the writing of some bindings which heavily rely on enumerations.
Endo
19-Feb-2012
[5187]
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.
Dockimbel
19-Feb-2012
[5188x2]
Can you make a `red` global variable in C when `red` is already use 
as an enumeration value?
Specification document fixed.
Endo
19-Feb-2012
[5190]
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.
Dockimbel
19-Feb-2012
[5191]
I mentioned it above, it needs a fix in the compiler and/or the runtime 
code.
Oldes
20-Feb-2012
[5192x4]
*** 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.
Endo
20-Feb-2012
[5196x2]
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.
Oldes
20-Feb-2012
[5198x3]
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.
Endo
20-Feb-2012
[5201x2]
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"
Oldes
20-Feb-2012
[5203x3]
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
Endo
20-Feb-2012
[5206]
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?)
Pekr
20-Feb-2012
[5207]
warning's good in such a case imo, or your app will most probably 
behave incorrectly in the runtime anyway, no?
Oldes
20-Feb-2012
[5208x2]
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.
Dockimbel
20-Feb-2012
[5210]
Oldes: I agree with your fix, the locally defined value should prevail 
over the enumeration value.
PeterWood
20-Feb-2012
[5211]
I've added the example of the proposed change to enum-test.reds (Enum-11).
Oldes
20-Feb-2012
[5212]
And so what is expected behaviour for:
#enum test! [a b]
f: func[a [c-string]][]
PeterWood
20-Feb-2012
[5213]
In that case isn't a local to the function?
Oldes
20-Feb-2012
[5214x2]
Is it possible to test warning message?
enum-redec-10 must be changed