Ada's core attributes

8.20: web.adda/ada/predefined attributes:
. what are Ada's reserved attributes?
here they are renamed for clarification
(these are just the most basic ones;
there are many more for floats, etc):
type'base  -- the unconstrained subtype;
enum in type'first .. type'last,
A'range(N) =  A'first(n) .. A'last(n) -- array's nth dimension;
type'value(enumcode number or image string);
type'image(value) is a string;
type'code(value) -- the integer representing the value (aka pos);
type'codebitsize -- obj's fixed size (when packed);
rec.component'codebitoffset;
type'imagesize -- #characters(for largest expression);
type'++(value) -- successor;
type'--(value) -- predecessor .

representing meta-values

5.10: adda/enums/the power of zero:
. the system should be interested in
reserving some values for representing
the state of being undefined or out-of-range .
. this though, can be done by system tagging;
ie, every type could inherit from system
to get a bit that indicates whether the var
is in a well-defined state or not .
. generally,
there is no reservable value available:
. most enum'value sequences start with zero
because most value ranges have a value
that is analogous to zero:
you first ask if there is any value,
if not then zero,
else since there is a value,
which one is it ?
eg, {off:0, red:1, yellow:2, green:3};
"(off) is the absence of a color,
so "(off) would be represented by zero;
[5.31: likewise,
some enums have a special purpose for the last value too;
so that can't be reserved either .]

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 } .