Re: enumeration literal/internal codes query

[arny@wayback.UUCP (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