adda's enumerated types

6.22: adda/type"enum:
. for the sake of readability,
adda`enums should be translated
directly to c`enums;
however, c`enums do need a lot of
helper functions in order to provide
ada-style functionality .
. it should also add -- in addition to Ada's way --
the same functionality for enums
that c has for pointers:
eg, if the ptr points at 4-byte ints,
then ptr+1 actually means ptr+4;
likewise for enums:
(e+1) means find the enum value
of next enum;
. if the enum is complicated by
non-consecutive values:
eg, { off, green:10, yellow:50, red:100 }
then it needs to generate a table
that enumerates the enum values:
eg, if the value will be in {0, 10, 50, 100}
then the table: value -> ordinal
is {0:0, 10:1, 50:2, 100:3};
with the ordinal value,
the encoded value is found from
an array lookup: {0, 10, 50, 100};
so if e=green+1; then
{ off, green:10, yellow:50, red:100
}(green) -> 10:
e= val#10 + ord#1 then
{0:0, 10:1, 50:2, 100:3}(10) -> 1:
e= ord#1 + ord#1 = ord#2 then
{0, 10, 50, 100}(+2) -> 50:
yellow
--. if there are only a few var's
it would be more efficient to
store both the ordinal and value in e .
. if values are consecutive
then after possibly shifting for a non-zero start,
the ordinal equals the value;
so, the enum`arithmetic functions need only
check for [out of range] .
. there should be unique type`names for
the 3 classes of enum types:
* subtype"simple-enum
has consecutive values that are
bijecting to names;
* subtype"encoding-enum has
non-consecutive bijections;
* subtype"entyping-enum is non-bijective:
there is no functional mapping
from code to name;
rationale for the name "(entyping):
traversing the values of the entyping-enum
then returns a sort of typing or
partitioning into equivalence classes:
eg, a mapping of enum`names to {0,1}
{ off:0, green:1, yellow:1, red:1 }
would have a traversal that returns
sets:
the first set is all names encoded as 0:
{ off }
the next set is names encoded as 1:
{ green, yellow, red } .