1. enum type
- Posted by irv 3 weeks ago
- 350 views
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
2. Re: enum type
- Posted by ChrisB (moderator) 3 weeks ago
- 296 views
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
3. Re: enum type
- Posted by jmduro 3 weeks ago
- 281 views
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
4. Re: enum type
- Posted by irv 4 days ago
- 117 views
Too bad it doesn't work like the docs claim. It would be useful in a program I'm working on right now.
5. Re: enum type
- Posted by petelomax 4 days ago
- 115 views
It works like that in Phix, apart from the fact that RED/GREEN/BLUE/BLACK are builtin constants and can't be overridden.
6. Re: enum type
- Posted by ghaberek (admin) 4 days ago
- 105 views
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.
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
7. Re: enum type
- Posted by ghaberek (admin) 4 days ago
- 103 views
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
8. Re: enum type
- Posted by jimcbrown2 (admin) 2 days ago
- 82 views
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 )