arny@wayback.UUCP (Arny B. Engelson) (01/09/89)
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
arny@wayback.UUCP (Arny B. Engelson) (01/11/89)
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
murphy@beatnix.UUCP (Michael Murphy) (01/12/89)
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-0900scott@shuksan.UUCP (Scott Moody) (01/14/89)
> > 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).
rracine@AJPO.SEI.CMU.EDU (01/14/89)
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
jbg@sei.cmu.edu (John Goodenough) (01/15/89)
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
bbadger@x102c.uucp (Badger BA 64810) (01/17/89)
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.
scott@shuksan.UUCP (Scott Moody) (01/20/89)
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
arny@wayback.UUCP (Arny B. Engelson) (02/01/89)
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