1. enum type

From the docs:

enum type color RED=4, GREEN=7, BLACK=1, BLUE=3 , PINK=10 end type 
 
? color(RED)   --> 1 
? color(GREEN) --> 2 
? color(BLACK) --> 3 
? color(BLUE)  --> 4 
? color(PINK)  --> 5 
 
constant color_names = {"rouge", "vert", "noir", "bleu", "rose"} 
 
puts(1, color_names[color(BLUE)]) --> bleu 

In real life:

irv@irv-desktop:~/new_gtk$ eui enums.ex 
1 
1 
1 
1 
1 
rouge 

Euphoria Interpreter v4.2.0 development 
   64-bit Linux, Using System Memory 
   Revision Date: 2025-01-24 03:31:36, Id: 22b5124 

new topic     » topic index » view message » categorize

2. Re: enum type

Hi Irv

So this works as expected on My Win system (not your IRL)

Incidentally, it looks like enum overrides the assignments for a list of variables - is this expected behaviour?

Cheers

Chris

new topic     » goto parent     » topic index » view message » categorize

3. Re: enum type

irv said...

In real life:

irv@irv-desktop:~/new_gtk$ eui enums.ex 
1 
1 
1 
1 
1 
rouge 

Euphoria Interpreter v4.2.0 development 
   64-bit Linux, Using System Memory 
   Revision Date: 2025-01-24 03:31:36, Id: 22b5124 

Same for me on Windows X64 with same release 4.2.0 development.

Jean-Marc

new topic     » goto parent     » topic index » view message » categorize

4. Re: enum type

Too bad it doesn't work like the docs claim. It would be useful in a program I'm working on right now.

new topic     » goto parent     » topic index » view message » categorize

5. Re: enum type

It works like that in Phix, apart from the fact that RED/GREEN/BLUE/BLACK are builtin constants and can't be overridden.

new topic     » goto parent     » topic index » view message » categorize

6. Re: enum type

irv said...

From the docs:

enum type color RED=4, GREEN=7, BLACK=1, BLUE=3 , PINK=10 end type 
 
? color(RED)   --> 1 
? color(GREEN) --> 2 
? color(BLACK) --> 3 
? color(BLUE)  --> 4 
? color(PINK)  --> 5 
 
constant color_names = {"rouge", "vert", "noir", "bleu", "rose"} 
 
puts(1, color_names[color(BLUE)]) --> bleu 

In real life:

irv@irv-desktop:~/new_gtk$ eui enums.ex 
1 
1 
1 
1 
1 
rouge 

Euphoria Interpreter v4.2.0 development 
   64-bit Linux, Using System Memory 
   Revision Date: 2025-01-24 03:31:36, Id: 22b5124 

Edit: it seems to work correctly on 4.1

$ eui -v 
Euphoria Interpreter v4.1.0 development 
   64-bit Linux, Using System Memory 
   Revision Date: 2015-02-02 14:18:53, Id: 5861:57179171dbed 
 
$ eui enumtest.ex 
1 
2 
3 
4 
5 
bleu 

And I can confirm it's not working on 4.2

$ ./build-linux-x64/eui -c build-linux-x64/eu.cfg -v 
Euphoria Interpreter v4.2.0 release 
   64-bit Linux, Using System Memory 
   Revision Date: 2024-11-17, Id: 5f6c867 
 
$ ./build-linux-x64/eui -c build-linux-x64/eu.cfg enumtest.ex 
1 
1 
1 
1 
1 
rouge 

I started digging into this and I'm more confused now that before I started. The way enum type is implemented is strange, to say the least.

ChrisB said...

Incidentally, it looks like enum overrides the assignments for a list of variables - is this expected behaviour?

Not sure what you mean by this. Could you provide an example?

-Greg

new topic     » goto parent     » topic index » view message » categorize

7. Re: enum type

It appears 4.1 emits the type routine as a call to find_from() with the literal values. This is the described behavior.

SubProgram [/home/ghaberek/Projects/OpenEuphoria/euphoria/source/enumtest.ex-color:00150]  [i1:160] 
    STACK SPACE: 2 
    Required:    2 
 
        [/home/ghaberek/Projects/OpenEuphoria/euphoria/source/enumtest.ex:1]  (1) 
     1: 176 160 161 146 163              # FIND_FROM: [i1:160], [LIT {4,7,1,3,10}:161], [LIT 1:146] => 
                                         #     [_temp_:163] 
     6: 028 150 162 163                  # RETURNF: [_temp_:163] block[162]                                     10: 043                              # BADRETURNF: 
End SubProgram [color:00150] 

However, 4.2 emits the type routine as a series of equal() or equal() or equal(), etc.

SubProgram [/home/ghaberek/Projects/OpenEuphoria/euphoria/source/enumtest.ex-color:00151]  [i1:161] 
    STACK SPACE: 10 
    Required:    10 
 
        [/home/ghaberek/Projects/OpenEuphoria/euphoria/source/enumtest.ex:1]  (1) 
     1: 153 161 152 163                  # EQUAL: [i1:161], [RED:152] => [_temp_:163] 
     5: 153 161 154 164                  # EQUAL: [i1:161], [GREEN:154] => [_temp_:164] 
     9: 009 164 163 165                  # OR: [_temp_:164], [_temp_:163] => [_temp_:165] 
    13: 153 161 156 166                  # EQUAL: [i1:161], [BLACK:156] => [_temp_:166] 
    17: 009 166 165 167                  # OR: [_temp_:166], [_temp_:165] => [_temp_:167] 
    21: 153 161 157 168                  # EQUAL: [i1:161], [BLUE:157] => [_temp_:168] 
    25: 009 168 167 169                  # OR: [_temp_:168], [_temp_:167] => [_temp_:169] 
    29: 153 161 159 170                  # EQUAL: [i1:161], [PINK:159] => [_temp_:170] 
    33: 009 170 169 171                  # OR: [_temp_:170], [_temp_:169] => [_temp_:171] 
    37: 208 165                          # DEREF_TEMP: [_temp_:165] 
    39: 208 167                          # DEREF_TEMP: [_temp_:167] 
    41: 208 169                          # DEREF_TEMP: [_temp_:169] 
    43: 209 163                          # NOVALUE_TEMP: [_temp_:163] 
    45: 209 164                          # NOVALUE_TEMP: [_temp_:164] 
    47: 209 166                          # NOVALUE_TEMP: [_temp_:166] 
    49: 209 168                          # NOVALUE_TEMP: [_temp_:168] 
    51: 209 170                          # NOVALUE_TEMP: [_temp_:170] 
    53: 028 151 162 171                  # RETURNF: [_temp_:171] block[162] 
    57: 043                              # BADRETURNF: 
End SubProgram [color:00151] 

The plot thickens. That's all I can do for now, but I'll revisit this again soon.

-Greg

new topic     » goto parent     » topic index » view message » categorize

8. Re: enum type

ghaberek said...

It appears 4.1 emits the type routine as a call to find_from() with the literal values. However, 4.2 emits the type routine as a series of equal() or equal() or equal(), etc.

The plot thickens. That's all I can do for now, but I'll revisit this again soon.

-Greg

Hi Greg,

I'm not 100% sure if this is the case, but I compared the tag on github for 4.1.0 (which seems to have been released back sometime in 2014 - man it's been a while) and the current master, https://github.com/OpenEuphoria/euphoria/compare/4.1.0...master

We ... have a lot of changes, to say the least. However, I identified what appears to be an enum related change to the parser around like 3699 of source/parser.e https://github.com/OpenEuphoria/euphoria/blob/master/source/parser.e#L3699

Which lead me to this commit https://github.com/OpenEuphoria/euphoria/commit/1dcfbffbb6b8390aa3753387281f9cfdcb294a7c for this ticket https://openeuphoria.org/ticket/525.wc back in 2015

I don't entirely grok this part of the code, but futher down in that commit I think I see where the find_from in 4.1.0 (see https://github.com/OpenEuphoria/euphoria/blob/4.1.0/source/parser.e#L3469 ) was removed, and where the use of equal() was substituted (see https://github.com/OpenEuphoria/euphoria/blob/master/source/parser.e#L4369 )

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu