From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 13 Sep 93 15:33:02 GMT
From: emery@mitre-bedford.arpa  (David Emery)
Subject: Re: thoughts on "holey" enumerated types
Message-ID: <EMERY.93Sep13103302@goldfinger.mitre.org>
List-Id: <comp.lang.ada>

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