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.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 19 Sep 92 01:18:23 GMT
From: wdl39!mab@ford-wdl1.arpa  (Mark A Biggar)
Subject: Re: Enumerations
Message-ID: <1992Sep19.011823.15070@wdl.loral.com>
List-Id: <comp.lang.ada>

In article <1992Sep18.175423.25826@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>In article <1992Sep18.154145.6086@wdl.loral.com> mab@wdl39.wdl.loral.com (Mark
 A Biggar) writes:
>[ stuff deleted]
>
>>.. I also do not believe that Ada9x gives any relief in this area.
>Your use of the word "relief" suggests that you think something is broken
>here. What's wrong with this? Ada - as a matter of design philosophy -
>tries to separate abstraction from implementation. You write down a sequence
>of enumeration literals; 99.9% of the time you could not care less what the
>corresponding bits are. For the 0.1% of the time when you do care (oh, OK,
>so maybe it's a few percent), you use repspecs. This is bad? What's
>wrong with the implementer choosing an easy set of _default_ reps as
>long as your repspec override is obeyed faithfully?

It was suggested early in the Ada9X effort that there should be attributes
like 'POS and 'VAL that delt with the real stored values of enumerations.
These were dropped as part of the Zero-budget simplifications.
All I ment by relief was that Ada9x did not provide a more convienent method
of dealing with the stroed values of enumeration literals then that provided
by Ada83.

--
Mark Biggar
mab@wdl1.wdl.loral.com