From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!wayback!arny
From: arny@wayback.UUCP (Arny B. Engelson)
Newsgroups: comp.lang.ada
Subject: Re: enumeration literal/internal codes query
Summary: clarification ('pos doesn't cut it)
Message-ID: <1499@wayback.UUCP>
Date: 10 Jan 89 23:15:41 GMT
References: <1494@wayback.UUCP>
Organization: AT&T Bell Labs, Whippany, NJ
List-Id: <comp.lang.ada>

In article <1494@wayback.UUCP>, arny@wayback.UUCP (Arny B. Engelson) writes:
> Here's the question:
>    After specifying internal codes for the literals of an enumeration type
>    using an enumeration representation clause, how do you (later in the
>    code) find out what internal codes were specified?
> 
>    Note that this question actually is the same whether or not an
>    enumeration rep clause is used.  How do you find out the internal codes?
> 
> Arny Engelson    (att,ihnp4,clyde)!wayback!arny    (201) 386-4816

After receiving 3 misguided, but well intended, responses (in one day)
suggesting I use the 'POS attribute, I thought I'd clarify my question.

'POS gives the position number, which always starts at 0 (RM 3.5.1),
and increments by 1 for each successor.  This has NOTHING TO DO with
the internal codes specified in an enumeration representation clause.

Also, I know Unchecked_Conversion can be used (by converting to an integer
type of the appropriate size), but this is extremely messy
(repeated instantiations for each enumeration type to be converted), and
not at all what I had in mind.  There should be a better way.

It seems to me that retrieving the internal codes being used to store an
object, whether specified by the programmer or assigned by the
implementation, should be provided for directly by a language feature
(such as an attribute).

Any comments from members of the ALIWG, members of the language maintenance
committee (or whatever it's called these days), or anyone else, are welcome.


  - Arny Engelson