Re: enum options
- Posted by Shawn Pringle Jul 18, 2008
- 890 views
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
Is your grow clause for using for flags we see so often in C interfaces where you can specify values by combining constants with binary or?
I don't think label is consistent with the usage in the rest of the language though. Enum isn't flow control. An enum is a special type. Is "fields" the name of the set of constants?
Now, "using routine_id". Could you explain what this means?
I would go with an example:
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
Now the above would not only define the constants but also the type,
Look at this header: procedure mem_linux_reprotect( atom addr, linux_mem_access_type pr )
Now pr is a new protection for linux_mem_access and the interpreter make sure that pr is some combination of READ, WRITE, EXEC or 0. Essentialy the procedural defniition of linux_mem_access_type() is:
return pr&(READ|WRITE|EXEC) == pr
more generally it would be
type enum typename [ ( [from start_value] [to end_value] [by additive_value] | [grow multiply_factor] | [using routine_id] ) ] foo, bar, ... end type
Finally, Often it would be useful but it nearly is always absent for the user, I.E. the programmer, to either through a bug report or on the screen to see the identifier's name rather than the numeric value. An option to include that would be useful for debugging purposes. This is normally done in C by using the macro processor
Shawn Pringle
