re: enumeration literal/internal codes query

re: enumeration literal/internal codes query

[rracine]

Arny Engelson asks:
>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?

The only way is by using UNCHECKED_CONVERSION.  

I have never heard an explanation as to why the POS attribute returns the
value as if the type had no representation clause.  There is no explanation
in the Rationale.

Roger Racine
C. S. Draper Laboratory, Inc.
rjr1287@draper.com

enumeration literal/internal codes query

[Arny B. Engelson]

A coworker came to me with what I thought was a simple question, but I
don't see a way to do what he wants.  Am I missing a language feature,
or is there a language feature missing?

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

Re: enumeration literal/internal codes query

[Arny B. Engelson]

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

Re: enumeration literal/internal codes query

[Scott Moody]

>
> 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).
>   - Arny Engelson
 
I too have run into all of the same problems that you have mentioned. The 'pos
doesn't work which leaves the Unchecked Conversion method. I would also
think that the language should provide some better (cleaner) method
of retrieving that value; especially since the language provides a
clean method of describing those values (using rep specs).

Re: enumeration literal/internal codes query

[Badger BA 64810]

In article <1074@shuksan.UUCP> scott@shuksan.UUCP (Scott Moody) writes:
>I too have run into all of the same problems that you have mentioned. The 'pos
>doesn't work which leaves the Unchecked Conversion method. I would also
>think that the language should provide some better (cleaner) method
>of retrieving that value; especially since the language provides a
>clean method of describing those values (using rep specs).

I've been wondering why you *want* to access the ``internal'' representation.
The standard use for representation clauses on enumeration types is to ``hide''
a specific encoding so that you *don't* have to deal with the ``ugly'' numeric
representation directly.  

The only thing I've thought of is to use it as an ``external representation''
to be written to a file.  Normally, of course, you would just instantiate 
SEQUENTIAL_IO on the enumeration type, or on a record type with a component
of the enumeration type.  But in that case, you don't really ``see'' the 
representation in the program, it only appears in the file.

So, please give an example of how accessing the representation would be useful.


Bernard A. Badger Jr.	407/984-6385   | ``Use the Source, Luke!''
Secure UNIX Products                   | That's not a bug! It's a feature!
Harris GISD, Melbourne, FL  32902      | Buddy, can you paradigm?
Internet: bbadger@x102c.harris-atd.com | 's/./&&/' Tom sed [sic] expansively.

Re: enumeration literal/internal codes query

[Scott Moody]

In article <1438@trantor.harris-atd.com>, bbadger@x102c.uucp (Badger BA 64810) writes:
> In article <1074@shuksan.UUCP> scott@shuksan.UUCP (Scott Moody) writes:
> 
> I've been wondering why you *want* to access the ``internal'' representation.
> The standard use for representation clauses on enumeration types is to ``hide''
> The only thing I've thought of is to use it as an ``external representation''
> to be written to a file.  Normally, of course, you would just instantiate 
> SEQUENTIAL_IO on the enumeration type, or on a record type with a component

Try:
 type opcodes is
     ( op_no_op,
       op_integer,
       op_string,
       op_long_integer);

    for opcodes use
      (  
         op_no_op               => 16#00#,
         op_integer             => 16#41#,
         op_string              => 16#52#,
         op_long_integer        => 16#63#);

   Note the nice and clean syntax that Ada has supplied.

In my case, I am writing the internal representations 
of a lot of data structures to a file. Unfortunately 
there is no mixed_sequential_io so everything
must be broken into a common data type (unsigned bytes in my case).
Thus someone needs to make this conversion outside of the 'sequential_io' 
package. I supply a function to make this conversion which hides some
of the burden.

I agree that a sequential_io package would be nice, especially a mixed_io.

-- scott

Re: enumeration literal/internal codes query

[Arny B. Engelson]

In article <1105@shuksan.UUCP>, scott@shuksan.UUCP (Scott Moody) writes:
> In article <1438@trantor.harris-atd.com>, bbadger@x102c.uucp (Badger BA 64810) writes:
> > In article <1074@shuksan.UUCP> scott@shuksan.UUCP (Scott Moody) writes:
> > I've been wondering why you *want* to access the ``internal'' rep.
> > The standard use for rep clauses on enumeration types is to ``hide''
> > The only thing I've thought of is to use it as an ``external rep''
> > to be written to a file.  Normally, of course, you would just instantiate 
> > SEQUENTIAL_IO on the enumeration type, or on a record type with a component

> In my case, I am writing the internal representations 
> of a lot of data structures to a file. Unfortunately 
> there is no mixed_sequential_io so everything
> must be broken into a common data type (unsigned bytes in my case).
> Thus someone needs to make this conversion outside of the 'sequential_io' 
> package. I supply a function to make this conversion which hides some
> of the burden.
> I agree that a sequential_io package would be nice, especially a mixed_io.
> 
> -- scott

   I think our local newsfeed lost Scott's original article (or I missed it).
But, since I originally raised this question, and never explained why I want
to know what the internal codes are, I thought I'd shed a little light.

   We have a distributed application, targeted to a heterogeneous mixture
of processors which communicate by (among other things) sending a wide
variety of packetized messages over a serial link.  Messages are also
created and sent to/from a host computer during debugging.  These messages
are defined precisely (down to the bit).  Some of the fields in these
messages are enumeration values that are defined in a common library package,
which is linked with application code on each of the processors.  Groups of
messages are also created (as scenario test cases) on the host and stored in
a file.
   Knowing the internal codes is helpful when these messages are created
(either by a processor or by a user attempting to debug the system), and
when these messages are interpreted.  As you can see, mixed_sequential_io
isn't very useful.
   This is just a partial description of the situation, but I hope I've
explained it sufficiently to at least gives an example of when this feature
would be useful.  As soon as my current deadline crunch passes, I will put
together an Ada 9X revision request, so that the idea is at least (hopefully)
fully explored.  Admittedly, as far as language deficiencies go, this is a
minor one (although assigning its importance a value from 1..10 seems very
subjective to me).

   Thanks to all those who took the time to reply to my earlier request.

  - Arny Engelson   att!wayback!arny   (201)386-4816

Re: enumeration literal/internal codes query

[John Goodenough]

In article Re: enumeration literal/internal codes query of 10 Jan 89 23:15:41
GMT arny@wayback.UUCP (Arny B. Engelson) writes:

>>    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?

>'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.

I know of no way other than Unchecked_Conversion to get at the actual internal
codes.  This has been remarked on a few times at language maintenance
committee meetings.  Robert Dewar (I think) has also pointed out that you
can't access the internal representation of _any_ data type in the language.
Even for integers, you only think you know the internal representation because
it is so commonly a signed, unbiased representation, but if an implementation
supports biased representation (e.g., when a record component is implemented
with two bits because the component has the range 4..6), you can't detect the
actual representation used any more than you can for enumeration literals.

To argue that this is a language deficiency worthy of being corrected in the
9X revision, you need to describe the programming requirement for which this
may be the correct solution, using the suggested revision request format.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: enumeration literal/internal codes query

[Michael Murphy]

The 'POS attribute can be used to find the position of the enumeration,
which is the same as the internal representation when there is no 
representation specification.  If there is a rep-spec on the enumeration,
then you do have a bit of a problem.  I believe that at least one 
implementation provides a 'REP attribute for this purpose, but you will
not find that on most compilers.  The obvious way to find the internal
representation in all cases is to use an unchecked conversion from the
enumeration value to an integer variable.  Unchecked_conversion is the
typing-loophole that allows you to manipulate your view of any object's
internal representation.

-- michael murphy
-- UUCP: {uunet|sun}!elxsi!elk!murphy
-- AT&T: 408-942-0900