Re: Unchecked_Conversion on different sized types -- problem?

["David A. Cobb" <superbiskit@home.com>]

Keith Thompson wrote:
> 
> "Mike Silva" <mjsilva@jps.net> writes:
> [...]
> > type T is ( BLACK, WHITE );
> >
> > for T use ( BLACK => 30, WHITE => 37 );
> 
> Enumeration representation clauses are, in my opinion, a poorly
> designed feature of the language.  The idea of assigning a numeric
> value to each element of an enumeration type is potentially useful,
> but the lack of a well-defined way to use get at the representation
> makes it nearly useless in most applications.
> 
> When Ada 83 was originally designed, it was intended that a
> representation clause should have as little effect as possible on the
> behavior of a type; it's the compiler's responsibility to generate
> code that "hides" the representation.  In this case, I think the
> language designers hid the representation too well.  During the Ada 95
> design, I think it was felt that enumeration representation clauses
> weren't used often and thus weren't worth fixing.  (I'm probably
> horribly misrepresenting the intent of the designers of both Ada 83
> and Ada 95; feel free to jump in and correct me.)
> 
> With the addition of a couple of predefined attributes, similar to
> 'Val and 'Pos but operating on the underlying representation rather
> than on position numbers, enumeration representation clauses could
> have been far more useful.  GNAT's 'Enum_Rep attribute provides part
> of this, but of course any code that uses it is non-portable.
> 
> --
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

I wasn't there, but I recall reading that representation clauses were
considered necessary by the embedded system folks because the
representation might be dictated by the hardware.  Consider a status
enumeration for an i-o device.  

Still, there's no way to make it pretty.

I've seen a lot of stuff where enumeration seems the appropriate
abstraction but they get all hung up because the enumeration requires
that ALL states be known to the package that declares the type.

IMNSHO, the way out is a private type with the various states
represented by functions.  As I recall, in a weird way the RM specifies
that references to the enum.value THIS are syntactically identical to
references to a 'Function This returns Enumerated_Thing;'

The critical thing about enumerated types is that they define an
ORDERING.  It is well defined to talk about ENUM_VAL_A < ENUM_VAL_B.
In is NOT particularly well defined to talk about 'if Device_State >
Ready . . .'
---------------------
A rusty practitioner.