Using the GNAT defined attribute: 'Enum_Rep

Using the GNAT defined attribute: 'Enum_Rep

[Marin David Condic, 561.796.8997, M/S 731-96]

    Here's a little problem which I could use some help handling:

    I get external data for my program which is extracted from the
    internal representation of an enumerated type. That is to say, I'm
    getting integers which correspond to the representation clause of
    the enumerated type, not the position. On input, they are read as
    integers and I'd like to convert them to the enumerated type.

    The ARM suggests using Unchecked_Conversion to get from here to
    there, but now you've got to create an integer type that is the
    same size as the enumerated type. Here's a code fragment:

    --
    type Temp_Integer is range Integer'First..Integer'Last ;
    for Temp_Integer'Size use User_Types.CL_Evt_Status'Size ;
                            --^^^^^^^^^^^^^^^^^^^^^^ The enumerated type.

    function
        CVT_Evt_Status
    is new
        Ada.Unchecked_Conversion (
            Source  => Temp_Integer ;
            Target  => User_Types.CL_Evt_Status) ;

    You can now use the CVT_Evt_Status function to get from the
    external integer to the internal representation. However, the
    declaration of Temp_Integer might not work because you don't know
    that the 'Size of the enumerated type is big enough for the range.
    You can easily build a custom one-off that will work if you know
    enough about the type and it's representation, but it would be
    nicer to have a general solution which will work for any
    enumerated type & representation.

    GNAT is nice enough to provide the attribute: 'Enum_Rep which
    returns a Universal_Integer of the internal representation of an
    enumerated object. (I'm surprised this isn't standard!) This is a
    great answer when I'm writing the data out - all I've got to worry
    about is that the enumeral doesn't create a constraint_error when
    assigned to an integer object for output. What I'd like is a
    corresponding "'Integer_Rep" (or some other more appropriate name)
    attribute which converted from a Universal_Integer to the internal
    representation of the enumerated type - risking only
    Constraint_Error if the integer is not a member of the
    representation set.

    Has anyone got a suggestion as to how this can be done more
    elegantly with some other attributes or Unchecked_Conversion? I
    don't see any simple way to do this. (Please don't suggest 'Pos
    and 'Val. These will work If and only if the representation is
    identical to the position numbers - what you get if you don't
    specify a representation. What I've got are representations with
    gaps in them.) Thanks for any suggestions you have to offer.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
  "I saw a bank that said "24 Hour Banking", but I don't have that much time."
        --  Steven Wright
===============================================================================

Re: Using the GNAT defined attribute: 'Enum_Rep

[W. Wesley Groleau x4923]

>     Here's a little problem which I could use some help handling:
> 
>     .... to create an integer type that is the
>     same size as the enumerated type. Here's a code fragment:
> 
>     type Temp_Integer is range Integer'First..Integer'Last ;
>     for Temp_Integer'Size use User_Types.CL_Evt_Status'Size ;
>                             --^^^^^^^^^^^^^^^^^^^^^^ The enumerated type.
> 
>     .... new  Ada.Unchecked_Conversion (
>             Source  => Temp_Integer ;
>             Target  => User_Types.CL_Evt_Status) ;

you've probably already discovered that Integer'First..Integer'Last
forces a minimum on Temp_Integer'Size.  And in Ada 83, the above 
would not be legal because 'Size is _defined_ as non-static, thus 
can't be used to specify another 'Size.  To get around this, I did

    CL_Evt_Status_Size : constant := ######;
    for CL_Evt_Status'Size use CL_Evt_Status_Size;

Now CL_Evt_Status_Size can be used anywhere that CL_Evt_Status'Size
can be used, and it will be static.

>      'Pos and 'Val. ... will work If and only if the representation is
>     identical to the position numbers - what you get if you don't
>     specify a representation. ....

Is this true ?  Seems to me it's legal (though I've never seen
it happen) for an implementation to generate anything it wanted
for a representation as long as ordering, indexing, etc. worked.

I can imagine a CPU where a bit per value is more efficient, i.e., 
an implicit

   for Enum use ( 0, 1, 2, 4, 8, 16, 32, ... );

though, again, I've never seen that done.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert Dewar]

W.W.G. says

<<Is this true ?  Seems to me it's legal (though I've never seen
it happen) for an implementation to generate anything it wanted
for a representation as long as ordering, indexing, etc. worked.>>


No, not at all, the whole point of enumeration types is that this is the
one place where Ada *does* have something to say about representation.
The ACVC interpretation (and hence what all Ada compilers do), is that
if you use an enumeration representation clause, then the representation
must match that of integers of the same size.

And of course Pos and Val will NOT match representations assigned in
this manner. Wes, if we believed your claim above, we would be believing
that enumeration representation clauses have no runtime semantics. That
is not the case!

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert A Duff]

In article <97082719523509@psavax.pwfl.com>,
Marin David Condic, 561.796.8997, M/S 731-96 <condicma@PWFL.COM> wrote:
>    The ARM suggests using Unchecked_Conversion to get from here to
>    there, but now you've got to create an integer type that is the
>    same size as the enumerated type. Here's a code fragment:

How about:

    type Temp_Integer is range 0..2**User_Types.CL_Evt_Status'Size;

and use Temp_Integer'Base?  Or:

    type Temp_Integer is mod User_Types.CL_Evt_Status'Size;

?

- Bob

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert A Duff]

In article <340D6C5D.2E53@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>...  And in Ada 83, the above 
>would not be legal because 'Size is _defined_ as non-static, thus 
>can't be used to specify another 'Size.

S'Size is static if S is a static subtype (in both Ada 83 and 95).

>>      'Pos and 'Val. ... will work If and only if the representation is
>>     identical to the position numbers - what you get if you don't
>>     specify a representation. ....
>
>Is this true ?

Yes.

>...  Seems to me it's legal (though I've never seen
>it happen) for an implementation to generate anything it wanted
>for a representation as long as ordering, indexing, etc. worked.

Yes, but 'Pos and 'Val still need to return what the RM says, which is
*not* based on the representation.

>I can imagine a CPU where a bit per value is more efficient, i.e., 
>an implicit
>
>   for Enum use ( 0, 1, 2, 4, 8, 16, 32, ... );

Fine, but the 'Pos values are still 0, 1, 2, 3, ...

>though, again, I've never seen that done.

Me neither.  We probably never will, either.

- Bob

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert A Duff]

In article <dewar.873592148@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>The ACVC interpretation (and hence what all Ada compilers do), is that
>if you use an enumeration representation clause, then the representation
>must match that of integers of the same size.

Right, although the RM doesn't say so.  In fact, the RM doesn't say that
the representation of all integer types of a given size has to be the
same.  Probably the RM should have nailed this point down.

In fact, doesn't GNAT use biased representations in some cases?  How
does that affect unch-conv from enum to biased-integer?

- Bob

Re: Using the GNAT defined attribute: 'Enum_Rep

[W. Wesley Groleau x4923]

Robert A Duff wrote:
> In article <340D6C5D.2E53@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
> >...  And in Ada 83, the above
> >would not be legal because 'Size is _defined_ as non-static, thus
> >can't be used to specify another 'Size.
> 
> >>      'Pos and 'Val. ... will work If and only if the representation is
> >>     identical to the position numbers - what you get if you don't
> >>     specify a representation. ....
> >Is this true ?
> Yes.

Note, I asked "is it true that the representation is identical
to the position numbers if you don't specify a rep" so by the rest
of your post the answer appears to be "not necessarily"
 
> >I can imagine a CPU where a bit per value is more efficient, i.e.,
> >an implicit
> >
> >   for Enum use ( 0, 1, 2, 4, 8, 16, 32, ... );
> 
> Fine, but the 'Pos values are still 0, 1, 2, 3, ...

> >though, again, I've never seen that done.
> 
> Me neither.  We probably never will, either.

Nevertheless, I will never write logic that depends on
_any_ internal representation unless _I_ or the RM specified 
that representation.  (Even though you and Dewar both said
the ACVC forces the answer to be "yes, it is true")

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Using the GNAT defined attribute: 'Enum_Rep

[Matthew Heaney]

In article <34145CCF.377F@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923"
<wwgrol@pseserv3.fw.hac.com> wrote:


>Whoa!  Communication breakdown.  I said "is this true?" to someone's 
>claim that the ABSENCE of an enum-rep-clause, makes the representation 
>the same as the 'pos.  For most CPUs, making the internal rep.
>the same as 'pos is probably the simplest and most efficient
>approach.  But please cite LRM-83 or LRM-95 if it is illegal for
>a compiler, given
>
>  type Enum is (Zero, One, Two, Three, Four, Five, Six, Seven );
>
>(with no rep-clause), please cite LRM-83 or LRM-95 if it is 
>illegal for an implementation to internally use
>
>  for Enum use (Zero  => 2#00000001#,
>                One   => 2#00000010#,
>                Two   => 2#00000100#,
>                Three => 2#00001000#,
>                Four  => 2#00010000#,
>                Five  => 2#00100000#,
>                Six   => 2#01000000#,
>                Seven => 2#10000000# );

The rule changed in Ada 95.  In Ada 83, the RM had nothing to say about the
representation of enumeration values, but every known implementation used
the same as T'Pos, so they made that the reference-manual-defined default
representation for Ada 95.  RM95 13.4 (8) states 

"For nonboolean enumeration types, if the coding is not specified for the
type, then for each value of the type, the internal code shall be equal to
its position number."

Therefore, your example is legal in Ada 83, and illegal in Ada 95.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Using the GNAT defined attribute: 'Enum_Rep

[Matthew Heaney]

In article <34147DAB.463@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923"
<wwgrol@pseserv3.fw.hac.com> wrote:


>Nevertheless, I will never write logic that depends on
>_any_ internal representation unless _I_ or the RM specified 
>that representation.

Again, the RM does define internal representation, in RM95 13.4 (8).  See
also paragraph 8a in the AARM.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Using the GNAT defined attribute: 'Enum_Rep

[W. Wesley Groleau x4923]

> <<Is this true ?  Seems to me it's legal (though I've never seen
> it happen) for an implementation to generate anything it wanted
> for a representation as long as ordering, indexing, etc. worked.>>
> 
> No, not at all, the whole point of enumeration types is that this is the
> one place where Ada *does* have something to say about representation.
> The ACVC interpretation (and hence what all Ada compilers do), is that
> if you use an enumeration representation clause, then the representation
> must match that of integers of the same size.
> 
> And of course Pos and Val will NOT match representations assigned in
> this manner. Wes, if we believed your claim above, we would be believing
> that enumeration representation clauses have no runtime semantics. That
> is not the case!

Whoa!  Communication breakdown.  I said "is this true?" to someone's 
claim that the ABSENCE of an enum-rep-clause, makes the representation 
the same as the 'pos.  For most CPUs, making the internal rep.
the same as 'pos is probably the simplest and most efficient
approach.  But please cite LRM-83 or LRM-95 if it is illegal for
a compiler, given

  type Enum is (Zero, One, Two, Three, Four, Five, Six, Seven );

(with no rep-clause), please cite LRM-83 or LRM-95 if it is 
illegal for an implementation to internally use

  for Enum use (Zero  => 2#00000001#,
                One   => 2#00000010#,
                Two   => 2#00000100#,
                Three => 2#00001000#,
                Four  => 2#00010000#,
                Five  => 2#00100000#,
                Six   => 2#01000000#,
                Seven => 2#10000000# );


-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert A Duff]

In article <mheaney-ya023680000809972005530001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>Again, the RM does define internal representation, in RM95 13.4 (8).  See
>also paragraph 8a in the AARM.

Ah yes, I had forgotten about that paragraph.  Sorry for the
misinformation.

By the way, if I were designing a language from scratch, I would say
that the compiler can do whatever it likes in the absence of rep
clauses.  But I would provide an easy way to say you want the "obvious"
representation (which is (0, 1, 2, ...) for enums).  The problem with
Ada 83 was that you had to write a whole bunch of stuff to say you want
what you would get anyway, which is why 13.4(8) exists.  That problem
still exists for record_rep_clauses, for example, although "pragma
Convention(C);" comes close to what I want, here.

- Bob

Re: Using the GNAT defined attribute: 'Enum_Rep

[Marin David Condic, 561.796.8997, M/S 731-96]

"W. Wesley Groleau x4923" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>Whoa!  Communication breakdown.  I said "is this true?" to someone's
>claim that the ABSENCE of an enum-rep-clause, makes the representation
>the same as the 'pos.  For most CPUs, making the internal rep.
>the same as 'pos is probably the simplest and most efficient
>approach.  But please cite LRM-83 or LRM-95 if it is illegal for
>a compiler, given
>
>  type Enum is (Zero, One, Two, Three, Four, Five, Six, Seven );
>
>(with no rep-clause), please cite LRM-83 or LRM-95 if it is
>illegal for an implementation to internally use
>
>  for Enum use (Zero  => 2#00000001#,
>                One   => 2#00000010#,
>                Two   => 2#00000100#,
>                Three => 2#00001000#,
>                Four  => 2#00010000#,
>                Five  => 2#00100000#,
>                Six   => 2#01000000#,
>                Seven => 2#10000000# );
>
    I'm not sure if you ever received my original response to you on
    this subject & I didn't post it to C.L.A. because I had not seen
    it in the listserver output from VM1.NODAK.EDU. (Is something
    wrong with this listserver? I seem to be missing out on large
    chunks of the conversation, seeing things badly out of date and
    not entirely sure that anything I post gets through.)

    Since you asked for the ARM references, I'll pass them along for
    the benefit of the curious:

>
>>      'Pos and 'Val. ... will work If and only if the representation is
>>     identical to the position numbers - what you get if you don't
>>     specify a representation. ....
>
>Is this true ?  Seems to me it's legal (though I've never seen
>it happen) for an implementation to generate anything it wanted
>for a representation as long as ordering, indexing, etc. worked.
>
>I can imagine a CPU where a bit per value is more efficient, i.e.,
>an implicit
>
>   for Enum use ( 0, 1, 2, 4, 8, 16, 32, ... );
>
>though, again, I've never seen that done.
>
    Section 3.5.1(7) of the ARM indicates that the position numbers of
    enumerations are 0, 1, ... as one would expect. Section 3.5.5
    talks about the 'Pos and 'Val operations which clearly are going
    to return 0, 1, ..., again as expected. Section 13.4 has all the
    details about enumeration representations and 13.4(8) states "For
    nonboolean enumeration types, if the coding is not specified for
    the type, then for each value of the type, the internal code shall
    be equal to its position number." Hence, the ARM requires internal
    representation of 0, 1, ... if you say nothing about it. Again,
    pretty much what your garden variety programmer is going to
    expect.

    I agree, there would be some food value in letting the
    implementation pick the representation which might best suit the
    machine (most commonly for booleans where representation might be
    faster using the sign bit - but that's allowed.) But I'm glad
    there's a certain clarity here about what you're going to get
    because (especially for us embedded guys where it really matters)
    surprises are what *really* hurt!

    It's interesting to read what the ARM says in 13.4(11) about using
    Unchecked_Conversion as the method of getting to the internal
    codes. Obviously, someone noticed that you'd need to do this and
    had a "preferred" method of getting there. But apparently, they
    missed the boat on how to guarantee an identical size between the
    two types in a manner that would self-correct. (Unless I'm being
    dense - which is why my original query was out there!) Maybe the
    intention was that if you knew enough to specify the
    representation then you'd likewise know enough to change the
    corresponding integer type (or Boolean array?) and that the one
    would be closely tied to the other.
===============================================================================

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "There's a fine line between fishing and standing on the shore
    looking like an idiot."

        --  Steven Wright
===============================================================================

Re: Using the GNAT defined attribute: 'Enum_Rep

[Marin David Condic, 561.796.8997, M/S 731-96]

Robert A Duff <bobduff@WORLD.STD.COM> writes:
>In article <97082719523509@psavax.pwfl.com>,
>Marin David Condic, 561.796.8997, M/S 731-96 <condicma@PWFL.COM> wrote:
>>    The ARM suggests using Unchecked_Conversion to get from here to
>>    there, but now you've got to create an integer type that is the
>>    same size as the enumerated type. Here's a code fragment:
>
>How about:
>
>    type Temp_Integer is range 0..2**User_Types.CL_Evt_Status'Size;
>
>and use Temp_Integer'Base?  Or:
>
>    type Temp_Integer is mod User_Types.CL_Evt_Status'Size;
>
>?
>
    That's pretty clever. Never thought of attempting to use the 'Size
    attribute in the type definition. I guess I had my brain wrapped
    around the axle with trying to use the 'Size attribute in the
    representation clause.

    Still, it would be very useful to have an attribute that is the
    inverse of 'Enum_Rep, taking a universal integer parameter and
    returning the corresponding enumeral - raising Constraint_Error if
    the integer did not match an enumeral internal representation. (Or
    possibly not raising the exception? Let it work a little like
    Unchecked_Conversion?)

    Thanks for the tip.

    MDC
Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "There's a fine line between fishing and standing on the shore
    looking like an idiot."

        --  Steven Wright
===============================================================================

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert A Duff]

In article <97090911205153@psavax.pwfl.com>,
Marin David Condic, 561.796.8997, M/S 731-96 <condicma@PWFL.COM> wrote:
>    Still, it would be very useful to have an attribute that is the
>    inverse of 'Enum_Rep, taking a universal integer parameter and
>    returning the corresponding enumeral - raising Constraint_Error if
>    the integer did not match an enumeral internal representation.

The Ada 9X team proposed a 'Rep attribute along these lines, but it was
nixed.  After all, doesn't U_C do the same?  (Now where's that smily
Robert recently asked about, which denotes sarcasm?  OTOH, Mark Twain,
who is probably the most sarcastic person ever born, never seemed to
need a mark to denote sarcasm.  OTTH, he didn't use smilies in his funny
stuff, either.)

>... (Or
>    possibly not raising the exception? Let it work a little like
>    Unchecked_Conversion?)

No, such an attribute ought to do the check.  With U_C, one needs to
check beforehand.

- Bob

Re: Using the GNAT defined attribute: 'Enum_Rep

[W. Wesley Groleau x4923]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> >a compiler, given
> >
> >  type Enum is (Zero, One, Two, Three, Four, Five, Six, Seven );
> >
> >(with no rep-clause), please cite LRM-83 or LRM-95 if it is
> >illegal for an implementation to internally use
> >
> >  for Enum use (Zero  => 2#00000001#,
> >                One   => 2#00000010#,
> >                Two   => 2#00000100#,
> >                Three => 2#00001000#,
> >                Four  => 2#00010000#,
> >                Five  => 2#00100000#,
> >                Six   => 2#01000000#,
> >                Seven => 2#10000000# );

>     I'm not sure if you ever received my original response to you on
>     this subject & I didn't post it to C.L.A. because I had not seen
>     it in the listserver output from VM1.NODAK.EDU. (Is something
>     wrong with this listserver? I seem to be missing out on large
>     chunks of the conversation, seeing things badly out of date and
>     not entirely sure that anything I post gets through.)

No, I didn't see it.  I am glad to be off of info-ada because it
lost about 50% of my posts, and often gave me duplicates of other
people's post many days after the first copy.

What started me off on the above topic was your apparently wanting
to depend on the default representation without specifying it.  I
was trying to suggest it may be easier to just specify the one you
want (as indeed, you were trying to do for 'size).  My post was
followed up by first a denial of something I hadn't said, then by
a correct answer followed by an explanation that contradicted it.
Finally Matthew Heaney again gave the correct answer and the LRM 95
reference.

Which is, for anyone confused,

> ... RM95 13.4(8) states
> "For nonboolean enumeration types, if the coding is not specified for the
> type, then for each value of the type, the internal code shall be equal 
> to its position number."
>
> Therefore, your example is legal in Ada 83, and illegal in Ada 95.

So if you know your code won't be used under Ada-83, you can depend
on the default.


None of this answers your original question about the 'Size, but as
you already know, Bob Duff offered a good idea.  I also had posted
an idea using a named number, but Bob Duff's idea is probably better
for most cases.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert Dewar]

Bob Duff says, replying to Matthew

<<Matthew Heaney <mheaney@ni.net> wrote:
>Again, the RM does define internal representation, in RM95 13.4 (8).  See
>also paragraph 8a in the AARM.

Ah yes, I had forgotten about that paragraph.  Sorry for the
misinformation.>>


This paragraph means absolutely nothing, let's quote it:

8   For nonboolean enumeration types, if the coding is not specified for the
type, then for each value of the type, the internal code shall be equal to
its position number.

But nowhere is internal code defined, and if you chase it around the RM,
you will find it is circular, and you can make it mean anything you want.
In no sense does this suggest anything about binary bit patterns.

Re: Using the GNAT defined attribute: 'Enum_Rep

[Robert Dewar]

Wes

<<So if you know your code won't be used under Ada-83, you can depend
on the default.>>

The comment about Ada 83 here is redundant except for academic language
lawyer purposes. All Ada 83 compilers ever written (and all those that
you can imagine being written), of course default to the standard
representation. The Ada 95 rule is merely stating an obvious, but
not explicitly stated, requirement.

Note carefully that in the case of enumeration representation types
declared in predefined units, you cannot count on any default
representation, since conceptually (and perhaps actually), there
may be enumeration representation clauses in private parts. One
would for example, not be at all surprised to see variations in
some cases of predefined enumeration types.