Re: Ada Enumerations

["Stanley R. Allen" <s_allen@hso.link.com>]

Matthew Heaney wrote:
> 
> 
> Personally, I feel that if you're always looking at the rep of the
> enumerands, then you probably don't want an enumeration type anyway.

That's a dead argument on the face of it.  If the language
permits me to *specify* the representation, then why doesn't
it permit me to *query* the specified values?  Permission is
granted in the case of 'Address and 'Size, so are the rules
different for enumeration representations?  In fact, a similar
attribute could be used, with the same orthogonality:

    for Color'Representation use
        (Red => 2, Green => 5, Blue => 8);
    ....
    X := Color'Representation (C);

(Much nicer than 'Enum_Rep, don't you think? :)

In any case, as you will see below, not using enumeration
types is not an option for me as an API developer.  Walk
a mile in my shoes.

>  That
> being said, why don't you just perform an instantiation of
> UC at the point of declaration of the type?
> 
> with Unchecked_Conversion, Interfaces;
> package Color_Types is
> 
>    type Color is (Red, Green, Blue);
>    for Color use (Red => 2, Green => 5, Blue => 8);
>    for Color'Size use 8;
>    function To_Rep is
>       new Unchecked_Conversion (Color, Interfaces.Unsigned_8);
> end Color_Types;
> 
> What's the big deal?  It's only 1 extra declaration
> (the instantiation of UC).
> 

It's ugly for one thing.  But it's also not my situation.
I'm not creating the enum types, my users are.

What if you are developing an interface so that users
can instantiate your software with *any* of their own
enumeration types?  My interface looks like this:

    generic
        type Enum is (<>);
    procedure Register_Enum_Type (Name : String);

This is part of a toolset that builds symbol table
information for user-defined types.  All of the Ada
information about the type must be captured in the
table, including the representation information.  It
is not possible to disallow types like your "Color"
type -- the users of the symbol table may depend on
that kind of thing.

We have restricted the user to 8, 16, and 32 bit
enumeration types, though this is potentially a
problem.  The way I am implementing this now is:

procedure Register_Enum_Type (Name : String) is
    E : Enum; -- dummy variable
    I8 : Integer_8;
    I16 : Integer_16;
    I32 : Integer_32;
    Values : array (Enum) of Integer;
begin
    for I in Enum loop
        case E'Size is
            when 8 =>
                Move1 (I'Address, I8'Address);
                Values (I) := Integer (I8);
            when 16 =>
                Move2 (I'Address, I16'Address);
                Values (I) := Integer (I16);
            when 32 =>
                Move4 (I'Address, I32'Address);
                Values (I) := Integer (I32);
            when others =>
                -- enum value must be 8, 16, or 32 bits
                raise Type_Error;
        end case;
    end loop;
    --- other logic
end Register_Enum_Type;

Move1, Move2, and Move2 are byte-copy operations like
C's memcpy.  This replaced the old way which was to
make three different instances of Unchecked_Conversion
in the body of the function:

    function Eto8 is new
        Unchecked_Conversion (Enum, Integer_8);
    function Eto16 is new
        Unchecked_Conversion (Enum, Integer_16);
    function Eto32 is new
        Unchecked_Conversion (Enum, Integer_32);

and use these instead of Move1, Move2, and Move3.

But then some compilers balked at the "unneeded"
UC instances.  For example, if Enum was 8 bits long,
some compilers would generate warnings or errors
for the other two, since Enum was neither 16 or 32
bits.  Even the warnings were an irritation, because
each user instance of the Register_Enum_Type (of
which there are hundreds) would generate warnings.
Hence the move away from UC altogether in this case.

-- 
Stanley Allen
mailto:s_allen@hso.link.com