Re: enum options
- Posted by CChris Jul 18, 2008
- 859 views
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
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.
So enum_meta returns all possible values then. It seems to be something that would be added everytime you used the grow statement. Why not make it automatic?
When you use the by clause the routine would be:
type other_enum( atom x ) return find( x, enum_meta("sequential_enum",META_LIST) ) end type
Because, while the grow 2 clause is a candidate for frequent use, grow 1.035 or grow 3 have their uses too. A systematic or_all() woudn't make sense there, or would fail.
I am not against
define_type(string enum_name, string type_name = make_identifier(enum_name)) though.
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
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.
No. Create a butltin: enum_name( "permissions", EXEC ) which would return "EXEC", the string. Then when you got an error. You could actually give the user a string. You would supply which enum was used to define EXEC.
That's the part I don't like. How would we do that?
What about enumerated types with the grow clause? It's easy, you test for each value with and in the binary case and you concatonate with pipes. In the string.
So enum_name( "permissions", EXEC|WRITE ) would yeild "EXEC|WRITE".
This one isn't an issue indeed.
I don't know what trace() should do if the enum had no name?
This may not be impossible, butlooks very, very tricky.
CChris
A program cannot tell the diference between NONE in the enum of permissions and the constant NULL, or another value which is equal to 0. The interpreter would have to keep track of which enum a constant came from and for combined flags it would be even trickier.
[/quote]
