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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 12 Sep 93 18:02:59 GMT
From: agate!howland.reston.ans.net!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co
m!mksol!strohm@ucbvax.Berkeley.EDU  (john r strohm)
Subject: Re: thoughts on "holey" enumerated types
Message-ID: <1993Sep12.180259.2237@mksol.dseg.ti.com>
List-Id: <comp.lang.ada>

In article <1993Sep11.192353.19703@jarvis.csri.toronto.edu> blaak@csri.toronto.
edu (Raymond Blaak) writes:
>The thread on converting integers to a sparse enumerated type has got
>me thinking.
>
>Couldn't enumerated types always be implemented as a contiguous range, such
>that use clauses to specify member ``positions'' just affected the 'POS and
>'VAL functions?

The key word in the above is "always".

The short answer is "No."

The longer answer is "No, because Ada allows the programmer to override
the compiler's default assignment of values to enumerated type names."

>That way enumerated type operations (especially loop traversal over a range,
>or array indexing) can always be efficient.

Loop traversal over a range can be made efficient, by introducing a "hidden"
induction variable that traverses a translation table in the place of the
iterated enumerated type variable.  I would be very surprised to learn that
a production-quality compiler DIDN'T do this.

Array indexing cannot be helped: by definition, when one deposits a value,
what is stored must be the correct bit pattern for the value.  Rep specs
are used to control that bit pattern.  When one later reads the value,
one gets back the same (arbitrary) bit pattern, so one has no option but
to do the translation for the array index.  Good Ada programmers understand
about this and avoid combining enumerated types with rep specs and array
indexing.