OpenEuphoria

2. Re: enum options

• Posted by jacques d. Jul 17, 2008
• 904 views
• Last edited Jul 18, 2008

export enum base 0 
   stuff, 
   nonsense 

enum field 
   name, 
   addr, 
   city, 
   state 
 
print(field[3]) => "state" -- nice to be able to do a reverse lookup sometimes 

In fact you can but not as as global setting as an individual setting, like this. enum name = 0, address, city, state

in the above example name = 0 address = 1, city = 2, state = 3

but what would you do with enum starting at zero as those are for use with sequence indexing which in euphoria start at 1?

jacques d.

4. Re: enum options

• Posted by irv Jul 17, 2008
• 906 views
• Last edited Jul 18, 2008

Oh, and as for what I would do with enums starting with 0?

Use 'em. And save some typing.

GTK, and most other libraries written in C, AFAIK, use base 0 for most everything.

Cutting and pasting hundreds of enums is bound to be more accurate than cutting, pasting, and then going back to change each group to start at 0. Which is what I'm doing right now.

6. Re: enum options

• Posted by Fernando Jul 17, 2008
• 910 views
• Last edited Jul 18, 2008

Just an (bad) idea:
How about replacing each "enum" with "enum dummy=-1," when you need zero based enums?
I don't test it in Eu 4.0 and the manual isn't clear, but, probably, the interpreter will generate duplicate symbol errors. However, it seems to me that a redeclaration of a symbol with the same value could be valid.

-Fernando

8. Re: enum options

• Posted by Derek Parnell Jul 17, 2008
• 910 views
• Last edited Jul 18, 2008

with zeroenum 
enum stuff, nonsense 
without zeroenum 
enum foo,bar 

with enum base=0  
enum stuff, nonsense  
  
with enum base=1  
enum foo, bar  
  
with enum base=10  
enum abc, def  

Yes, that was my initial thinking but for the purpose of this example I wanted to keep it simple. The base=N is kinda nice but resetting it could be problematic. For example ...

with enum base = 1 
enum foo, bar 
with enum base = 4 
enum qwerty, asdfgh 
. . .  
without enum base -- ??? resets to one 
enum poiuy, trewq 

with enum base=10 incrementor 10  
enum ten, twenty, thirty  
  
with enum base=1 incrementor *2  
enum one, two, four, eight, sixteen  

Yes it would be worthwhile, especially the *2 for hex-flags used in most UI programming.

I'm worried about scope creep for 4.0 though.

10. Re: enum options

• Posted by Salix Jul 18, 2008
• 889 views

Khm. I just do not understand this discussion. Why do you want to introduce a new keyword ("base") and even more confuse newbies with more complicated syntax ("with base i") if all you need is something that you already have?

enum stuff=0, 
    nonsense 

Please do not tell me that you want to "save some typing".

Regards,

Salix {:-.

12. Re: enum options

• Posted by CChris Jul 18, 2008
• 911 views

with enum base = 1 
enum foo, bar 
with enum base = 4 
enum qwerty, asdfgh 
. . .  
without enum base -- ??? resets to one 
enum poiuy, trewq 

There is a little known include file in win32lib that is called series.e. It implements all of the above and more. Why not simply make it a standard include? No need to ask for a permission.

Doing this would make a difference between builtin enums as were implemented and series. But I don't think it would be terribly difficult to put this code inside the interpreter proper. ?ot in 4.0 alpha, there is some urgency to release something. And there are issues to blend the syntax into known enums. I had tried to push for named enums, but....

How about this?

enum [ ( [from start_value] [to end_value]  
         [by additive_value] | [grow multiply_factor] | [using routine_id]  
         [label "fields"] ) ] 
 foo, 
 bar, 
... 

The brackets only show optional components, and are not to be written.

The parentheses mark the limits of the option list as opposed to the member list. I'd have nothing against using { } instead. Just some pair of delimiters currently not expected after enum.

In keeping with other labels currently in the language, the enum identifier is a string. However, contrary to current other labels, it may need to hold a valid identifier so as to be able to query properties of the enum. This restriction could be removed if we implement the query as enum_meta("fields", ENUM_FROM). You get the idea.

CChris

14. Re: enum options

• Posted by CChris Jul 18, 2008
• 878 views

enum [ ( [from start_value] [to end_value]  
         [by additive_value] | [grow multiply_factor] | [using routine_id]  
         [label "fields"] ) ] 
 foo, 
 bar, 
... 

Yes, and the permission example you give later is simply correct.

enum is a for loop with a twist applied to generating constants. In another language, you could say %FOR %I=1 %TO 4;%DO; %LET IDENT=names[&I]; &IDENT = &I,; %END; the last trailing comma needing extra care, left out.

That's why I think presenting an enum as as close as possible as a for loop makes sense. So it can have a label, which is the name of the enum. And if you want to query the properties of an enum, you need a name for it. I find the latter obvious, but some other people never got it.

Use a custom function to define what the next value in the enum is. Adding a constant or multiplying by a constant are frequent cases, but you can use a generic iterator. The latter takes current value and returns next value.

function next_value(integer p) return p*p end function

enum (using routine_id(next_value")) three = 3, three_squared, 9 three_power_4, 81 three_power_8, 6561 unrelated_constant = 123

Admittedly, the "from" clause could be removed, I left it in for the purpose of uniform coding. Everything in the ( ) is optional. Overriding with an explicit = is still possible. You can always insert values that didn't fit in the pattern at the end. The "to" part may not be needed either - I'm less sure of this.

The above would be implemented as

constant  
   three = 3,  
   three_squared = call_func(rid,{three}),  
   three_power_4 = call_func(rid, {three_squared}), 
-- ... 

type enum linux_mem_access_type from 1 to 8 grow 2 
-- check the C docs before using this. :) 
 READ, 
 WRITE, 
 EXEC, 
 NONE = 0 
end type 

I think one of the meta properties of an enum could be the whole set of values it takes, so this syntax would not be necessary.
if find(something,enum_meta("permissions", META_LIST)) then -- ok
assuming you used a label "permissions" clause.

type enum typename [ ( [from start_value] [to end_value]  
         [by additive_value] | [grow multiply_factor] | [using routine_id]  
         ) ] 
 foo, 
 bar, 
... 
end type 

Why not use what we have?

type permissions_mask(atom x) return x = and_bits(x, or_all(enum_meta("permissions",META_LIST))) end type

Ok, or_all() is not yet in std/math.e, but should be there.

This means that x = EXEC wouldn't simply store 4 in x, but store something like {"permissions","EXEC",4}, in an adequate way?

Looks good at a glance. trace() could show EXEC instead of 4. Dealing with Windows messages would be so much easier. Nice.
What should trace(1) display after x = or_bits(x, READ)? I think it will be hopelessly outsmarted if asked to obviously answer READ | EXEC.

I don't know what trace() should do if the enum had no name?

This may not be impossible, butlooks very, very tricky.

CChris

16. Re: enum options

• Posted by Matt Lewis Jul 18, 2008
• 887 views

The last thing I want to do is to go through the source code for a C-compiler. I'm not sure what purpose this would serve, in any case.

I can't imagine how it would make anything easier when translating to C code.

This suggestion assumes that the most common usage of enums will be for wrapping C code. I doubt this to be the case. And I care more for making euphoria easier for euphoria programmers than for theoretical users coming from another language. They know that they're using a different language. Since we're actually programming in euphoria, we should follow euphoria conventions, and starting at 1 is much more useful. It's really not that difficult to add in the "= 0" to the first enum, if that's the requirement.

Further, I think that the "with base=n" will lead to difficult to maintain code. I think that if you need some weirdness, it's better to explicitly declare it. If you're creating a set of bit flags, don't use enums. Use constants. It will be much clearer for everyone reading the code.

Matt

18. Re: enum options

• Posted by Bernie Jul 18, 2008
• 895 views

Matt:

I hope this doesn't wrap

What I was trying to point out was that the way being discussed was too complicated and confusing for a user.

Heres is a simple idea.

The reserved word enum would be considered as a constant and have 2 forms.

enum or global enum depending on its scope.

example :

enum 1 <<== this value following enum is the increment or decrement value.
foo = 0, <<== sets the starting point
apple,
banna, <<== each coma causes an increment
orange,
barr,
beer, <<== this is 5
beef = 23, <<== this changes our count value
telephone, <<== this is 24
bicycle; <<== semicolon ends the enumeration

20. Re: enum options

• Posted by CChris Jul 18, 2008
• 853 views

If you only need to tweak one or two enums in a program, this approuach is correct. If you have scores of them, it is not correct at all. At least terrbly unpractical.

Isn't "with base n" explicit? I don't understand. It will also help Basic users, who have an Options Base n directive as well.

Why?

And much more tedious to code. I cannot see how the example Shawn posted is not clear. Could you elaborate? By the ay, nothing prevents you from adding comment marks with an explicit value to the enum.

Comments have a precise purpose in the (any) language: tell reader things a machine doesn't need to know, or in a different way. The language constructs do not need to duplicate one another's functionality, and this applies to coments just as well.

CChris

22. Re: enum options

• Posted by Matt Lewis Jul 18, 2008
• 869 views

It's not as bad as you say. Most of the time, you can cut and paste from C source, and do some find and replace. I think I've done as much of this as anyone has, and it's somewhat of a pain, but the reality is that you're most commonly dealing with simple macros, not enums, so you have to go back and add equals signs, commas and change from C-style hex (0xdeadbeef) to euphoria style (#DEADBEEF). Has anyone ever actually had to convert scores of enums? Even so, it's the addition of a single = 0 to each one. And, it's a one-time cost.

Bottom line, there is no practical way to convert large amounts of code from another language.

It's explicit wherever that statement is, which is not necessarily where the enum is declared.

Because then it's more obvious what they're for. That's just my opinion. The values really stand out.

It's adding complication to something for basically zero benefit. If I'm going to put comments in, why would I use an enum? The only place I could see using a comment for an enum value is within a long list, in order to be able to figure out which value was which, but even then, it would only be every 5 or 10, or something similar. Doing this for bit flags would be as inane as:

    i +=1 -- increase i by one 

Matt

24. Re: enum options

• Posted by CChris Jul 18, 2008
• 893 views

<snipped the practicality part, Irv is more qualified to comment on it/>

Another scale issue.
If you have a couple enums to tweak, it is not neeeded. If you have a lot of them, then chances are that all of them are to be tweaked. And then the need to be explicit disappears, as all enums would be treated the same.

Don't get me wrong. I prefer the (from start_value ...) form. But your point was I think not much justified.

If the explicit values matter, then indeed use plain constants, whether for flags or anything else. If they don't, use enums for flags or anything else. Relevant names are often the best way out of the problem. They are part of the commenting.

    i +=1 -- increase i by one 

Since there is less code to convey the same semantics, it brings more simplicity rather than complexity. I agree with your last point about comments. But I see it buttressing my position more than yours.

CChris

26. Re: enum options

• Posted by jacques d. Jul 18, 2008
• 915 views

Irv, if you do alot of C library binding, you should rather write an euphoria script to parse C .h files to extract all #define and convert to euphoria code. Personnaly it's what I have done. windows sdk has thousands of #define, it's quite a good investment to write such a parser.

jacques d.

28. Re: enum options

• Posted by jacques d. Jul 18, 2008
• 856 views
• Last edited Jul 19, 2008

euphoria 4.0 alpha is not out yet adn we are discussing complicated enum. I agree with Matt on that, leave it as it is defined in 4.0.

jacques d.