Re: thoughts on "holey" enumerated types

[emery@mitre-bedford.arpa (David Emery)]

One of the 'problems' with enumeration representation specs is that
they can be a maintenance problem when the actual ordering of the type
is not important.  

Ordering is important for some enumeration types.  For instance,
character types need a sort order, the days of the week are ordered
(Wednesday follows Tuesday and preceeds Thursday, etc.)

For other enumeration types, there is no 'abstract order', such as with
everyone's favorite:

	type Fruit is (Apple, Pear, Orange);

The problem occurs when you use an representation clause on a type
with no 'abstract order'.  So, for one implementation/representation
of type Fruit, the following works just fine:

	for Fruit use (Apple =>1 , Pear => 2, Orange => 4);

The problem occurs when the set of values is not in the correct order.
The following is NOT LEGAL:
	
	for Fruit use (Apple =>1, Pear => 4, Orange => 2);

The enumeration representation values MUST follow the ordering given
in the type definition.  

I've run into this interfacing with C a lot.  Consider:

	#define APPLE 1
	#define PEAR 2
	#define ORANGE 4

	(void) juicer (int x);	/* maybe not strictly ANSI C, but you get
				 * the idea... */

Usually the idea is to map such structures to an enumeration type.
But if another C implementation comes up with 
	
	#define APPLE 1
	#define PEAR 4
	#define ORANGE 2

You have the illegal situation I pointed out earlier.  

So my rule is to NOT use enumeration representation clauses on
enumeration types where there is no specific 'abstract' ordering
clause.  Instead, I do the following:

	package spec:

	type Fruit is (Apple, Pear, Orange);

	procedure Juicer (the_fruit : Fruit);	

	package body:

	procedure Juicer_in_C (fruit_int : integer);
	pragma interface (C, Juicer_in_C);

	type Representation_Enumeration is array (Fruit) of Integer;
	Fruit_Rep : constant Representation_Enumeration
		  := (Apple => 1, Pear => 2, Orange => 4);

	procedure Juicer (the_fruit : fruit)
	is
	begin
	  Juicer_in_C (Fruit_Rep (the_fruit));
		-- for any reasonable compiler, the cost of this
		-- is a single indirect addressing operation.
	end Juicer;

The other advantage of this scheme is that changing the representation
is hidden in the body of the package, so that a change to the values
in the representation doesn't cause a recompilation of every unit that
depends on the public definition of the enumeration type.

				dave