Rep Specing Variant Records

Rep Specing Variant Records

[R.B. Love]

I want to understand how a variant record gets rep spec'd.  Let's say I 
have a sample of my record:

type stuff(has_extra:boolean) is
record
    foo: integer;
    bar: integer;
    case has_extra
        when true =>
            blah : float;
        when false =>
            null;
    end case;
end record;

for stuff use
record
    foo at 0 range 0..31;
    bar at 4 range 0..31;
end;

type normal_stuff is new stuff(has_extra=>false);
type good_stuff is new stuff(has_extra=>true);

for good_stuff use
record
    blah at 12 range 0..31;
end record;

for normal_stuff'size use 64;  -- 8 bytes
for good_stuff'size use 96;    -- 12 bytes

First, does the discriminant take up any size in the record?  When I 
tried this with a tagged record, I was told that my placement at 0 
bytes off set classed with the tag.  That's no good.

Second, does the layout of normal_stuff look like I expect it would, 
that is, the same as stuff?

Does the good_stuff record have a complete rep spec?

Thanks for any replies.  I see books covering the rep spec of plain 
records but none seem to cover variant records.

Re: Rep Specing Variant Records

[Petter]

Yes, discriminants do take up size.

This is how I would do it:

type Stuff (Has_Extra : Boolean) is record
     Foo : Integer;
     Bar : Integer;
     case Has_Extra is
         when True =>
             Blah : Float;
         when False =>
             null;
     end case;
 end record;

 for Stuff use record
     Has_Extra at  0 range 0 .. 31;
     Foo       at  4 range 0 .. 31;
     Bar       at  8 range 0 .. 31;
     Blah      at 12 range 0 .. 31;
 end record;

type Other_Stuff (Has_Blah : Boolean) is record
     Foo : Integer;
     Bar : Integer;
     case Has_Blah is
         when True =>
             Blah : Float;
         when False =>
             Blip : Integer;
     end case;
 end record;

 for Other_Stuff use record
     Has_Blah  at  0 range 0 .. 31;
     Foo       at  4 range 0 .. 31;
     Bar       at  8 range 0 .. 31;
     Blah      at 12 range 0 .. 31;
     Blip      at 12 range 0 .. 31;
 end record;

Re: Rep Specing Variant Records

[Martin]

On Sep 16, 2:22 am, R.B. Love <rbl...@airmail.net> wrote:
[snip]
> First, does the discriminant take up any size in the record?  When I
> tried this with a tagged record, I was told that my placement at 0
> bytes off set classed with the tag.  That's no good.

You need to determine 'has_extra' from somewhere (otherwise, how do
you know what variant you are using?) - are you getting it from a
different location that that will hold 'normal_stuff'/'good_stuff'?

You can move the descriminent to a passed the end of the last
component...it doesn't have to be the first item but I suspect that
you've very much in the realms of what your compiler would allow at
that point. The 99.999% case is that it is the 1st item.

Cheers
-- Martin

Re: Rep Specing Variant Records

[Adam Beneschan]

On Sep 15, 6:22 pm, R.B. Love <rbl...@airmail.net> wrote:
> I want to understand how a variant record gets rep spec'd.  Let's say I
> have a sample of my record:
>
> type stuff(has_extra:boolean) is
> record
>     foo: integer;
>     bar: integer;
>     case has_extra
>         when true =>
>             blah : float;
>         when false =>
>             null;
>     end case;
> end record;
>
> for stuff use
> record
>     foo at 0 range 0..31;
>     bar at 4 range 0..31;
> end;
>
> type normal_stuff is new stuff(has_extra=>false);
> type good_stuff is new stuff(has_extra=>true);
>
> for good_stuff use
> record
>     blah at 12 range 0..31;
> end record;
>
> for normal_stuff'size use 64;  -- 8 bytes
> for good_stuff'size use 96;    -- 12 bytes
>
> First, does the discriminant take up any size in the record?

In "stuff", it almost certainly takes space.  If you have a procedure
with a parameter X of type "stuff", and that procedure looks at
X.Has_Extra, the procedure has to get that data from somewhere, and it
will almost certainly get it from some field in X.  The discriminant
*could* be passed as a separate parameter, but that would be atypical.

For your derived types, normal_stuff and good_stuff, whether the
discriminant takes space depends on the implementation.  If you didn't
put any rep clauses on those types, they would probably have the exact
same representation as "stuff" because then type conversions would be
implemented just as straight copy operations.  But eliminating the
space for the discriminant is also possible.  (By the way, you can't
put a rep clause on the derived type under certain circumstances---see
13.1(10)).


> When I
> tried this with a tagged record, I was told that my placement at 0
> bytes off set classed with the tag.  That's no good.

Tagged records are a completely different animal, here.  First of all,
you cannot declare a type extension and rearrange any fields
(including discriminants) that existed in the parent type; you
couldn't get dispatching to work if you were allowed to rearrange
those fields.  You can only use a rep clause to rearrange new fields
in the type extension.  Second, you definitely can't move the tag to a
different place than in the parent type.  That would just blow
everything up.

Finally, although it's theoretically possible to have tags in
different places for two different (non-derived) tagged types, it
makes implementing the language a lot more difficult.  This is even
more true now that interface types have been introduced in Ada 2005.
(If you declare a root type Root_Type with a tag in a nonstandard
place, and then later "type Child is new Root_Type and Interface_Type
with...", then how is an operation on Interface_Type'Class going to
know where to find the tag if you give it a Child?)  So it is entirely
reasonable for a compiler to insist on the tag being in a set place
for every tagged type.

I don't know what you say this is "no good"---what are you trying to
accomplish?  Whatever it is, you're probably going about it wrong.


> Second, does the layout of normal_stuff look like I expect it would,
> that is, the same as stuff?

If the 'Size clause on Normal_Stuff is legal, then probably not.
Stuff has to have room for two integers, a float, and a Boolean; if
Integer'Size is at least 16 and Float'Size is at least 32, then
Stuff'Size will be larger than 64, which means that the only way
Normal_Stuff'Size could be legally 64 would be for the compiler to not
allocate space for some fields.  That may mean not allocating size for
Blah since it will never exist in a Normal_Stuff anyway.  But when the
compiler realizes it will need to rearrange fields, there's no telling
what it will do.

Even if Integer'Size is 16, it's entirely possible that the compiler
will allocate 32 bits for Foo and Bar to help with the machine's
alignment requirements.  If that's the case, and if it accepts "for
Normal_Stuff'Size use 64" as legal, it will need to rearrange things.

So the answer to your question is "maybe, maybe not".


> Does the good_stuff record have a complete rep spec?

I don't know what you mean by this.  The language doesn't require that
a rep spec specify every field.  If you don't, the compiler will put
the additional fields anywhere it feels like (and not necessarily in
the same place where they exist in a Stuff).  So this is a legal rep
spec.

                                       -- Adam

Re: Rep Specing Variant Records

[Robert Love]

First, thanks to all who answered my question.

My big concern about the presence of a discriminant in the derived type 
is that I'm shipping the record out via ether net to a C client to 
read.  The C program will not tolerate the extra discriminate.

I have two very similar layouts in the input and output data.  I had 
hoped to use variant records to save me some typing and coding.  I now 
believe I will have to have two complete records, one for input and one 
for output that will have 80% common structure.  Oh, well, it's just 
more typing.




On 2009-09-16 10:03:37 -0500, Adam Beneschan <adam@irvine.com> said:

> On Sep 15, 6:22�pm, R.B. Love <rbl...@airmail.net> wrote:
>> I want to understand how a variant record gets rep spec'd. �Let's say I
>> have a sample of my record:
>> 
>> type stuff(has_extra:boolean) is
>> record
>> � � foo: integer;
>> � � bar: integer;
>> � � case has_extra
>> � � � � when true =>
>> � � � � � � blah : float;
>> � � � � when false =>
>> � � � � � � null;
>> � � end case;
>> end record;
>> 
>> for stuff use
>> record
>> � � foo at 0 range 0..31;
>> � � bar at 4 range 0..31;
>> end;
>> 
>> type normal_stuff is new stuff(has_extra=>false);
>> type good_stuff is new stuff(has_extra=>true);
>> 
>> for good_stuff use
>> record
>> � � blah at 12 range 0..31;
>> end record;
>> 
>> for normal_stuff'size use 64; �-- 8 bytes
>> for good_stuff'size use 96; � �-- 12 bytes
>> 
>> First, does the discriminant take up any size in the record?
> 
> In "stuff", it almost certainly takes space.  If you have a procedure
> with a parameter X of type "stuff", and that procedure looks at
> X.Has_Extra, the procedure has to get that data from somewhere, and it
> will almost certainly get it from some field in X.  The discriminant
> *could* be passed as a separate parameter, but that would be atypical.
> 
> For your derived types, normal_stuff and good_stuff, whether the
> discriminant takes space depends on the implementation.  If you didn't
> put any rep clauses on those types, they would probably have the exact
> same representation as "stuff" because then type conversions would be
> implemented just as straight copy operations.  But eliminating the
> space for the discriminant is also possible.  (By the way, you can't
> put a rep clause on the derived type under certain circumstances---see
> 13.1(10)).
> 
> 
>> When I
>> tried this with a tagged record, I was told that my placement at 0
>> bytes off set classed with the tag. �That's no good.
> 
> Tagged records are a completely different animal, here.  First of all,
> you cannot declare a type extension and rearrange any fields
> (including discriminants) that existed in the parent type; you
> couldn't get dispatching to work if you were allowed to rearrange
> those fields.  You can only use a rep clause to rearrange new fields
> in the type extension.  Second, you definitely can't move the tag to a
> different place than in the parent type.  That would just blow
> everything up.
> 
> Finally, although it's theoretically possible to have tags in
> different places for two different (non-derived) tagged types, it
> makes implementing the language a lot more difficult.  This is even
> more true now that interface types have been introduced in Ada 2005.
> (If you declare a root type Root_Type with a tag in a nonstandard
> place, and then later "type Child is new Root_Type and Interface_Type
> with...", then how is an operation on Interface_Type'Class going to
> know where to find the tag if you give it a Child?)  So it is entirely
> reasonable for a compiler to insist on the tag being in a set place
> for every tagged type.
> 
> I don't know what you say this is "no good"---what are you trying to
> accomplish?  Whatever it is, you're probably going about it wrong.
> 
> 
>> Second, does the layout of normal_stuff look like I expect it would,
>> that is, the same as stuff?
> 
> If the 'Size clause on Normal_Stuff is legal, then probably not.
> Stuff has to have room for two integers, a float, and a Boolean; if
> Integer'Size is at least 16 and Float'Size is at least 32, then
> Stuff'Size will be larger than 64, which means that the only way
> Normal_Stuff'Size could be legally 64 would be for the compiler to not
> allocate space for some fields.  That may mean not allocating size for
> Blah since it will never exist in a Normal_Stuff anyway.  But when the
> compiler realizes it will need to rearrange fields, there's no telling
> what it will do.
> 
> Even if Integer'Size is 16, it's entirely possible that the compiler
> will allocate 32 bits for Foo and Bar to help with the machine's
> alignment requirements.  If that's the case, and if it accepts "for
> Normal_Stuff'Size use 64" as legal, it will need to rearrange things.
> 
> So the answer to your question is "maybe, maybe not".
> 
> 
>> Does the good_stuff record have a complete rep spec?
> 
> I don't know what you mean by this.  The language doesn't require that
> a rep spec specify every field.  If you don't, the compiler will put
> the additional fields anywhere it feels like (and not necessarily in
> the same place where they exist in a Stuff).  So this is a legal rep
> spec.
> 
>                                        -- Adam

Re: Rep Specing Variant Records

[Niklas Holsti]

Robert Love wrote:
> First, thanks to all who answered my question.
> 
> My big concern about the presence of a discriminant in the derived type 
> is that I'm shipping the record out via ether net to a C client to 
> read.  The C program will not tolerate the extra discriminate.

Have you looked at pragma Unchecked_Union (B.3.3)?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Rep Specing Variant Records

[Martin]

On Sep 17, 3:39 am, Robert Love <rbl...@airmail.net> wrote:
> First, thanks to all who answered my question.
>
> My big concern about the presence of a discriminant in the derived type
> is that I'm shipping the record out via ether net to a C client to
> read.  The C program will not tolerate the extra discriminate.
>
> I have two very similar layouts in the input and output data.  I had
> hoped to use variant records to save me some typing and coding.  I now
> believe I will have to have two complete records, one for input and one
> for output that will have 80% common structure.  Oh, well, it's just
> more typing.
>
> On 2009-09-16 10:03:37 -0500, Adam Beneschan <a...@irvine.com> said:
>
> > On Sep 15, 6:22 pm, R.B. Love <rbl...@airmail.net> wrote:
> >> I want to understand how a variant record gets rep spec'd.  Let's say I
> >> have a sample of my record:
>
> >> type stuff(has_extra:boolean) is
> >> record
> >>     foo: integer;
> >>     bar: integer;
> >>     case has_extra
> >>         when true =>
> >>             blah : float;
> >>         when false =>
> >>             null;
> >>     end case;
> >> end record;
>
> >> for stuff use
> >> record
> >>     foo at 0 range 0..31;
> >>     bar at 4 range 0..31;
> >> end;
>
> >> type normal_stuff is new stuff(has_extra=>false);
> >> type good_stuff is new stuff(has_extra=>true);
>
> >> for good_stuff use
> >> record
> >>     blah at 12 range 0..31;
> >> end record;
>
> >> for normal_stuff'size use 64;  -- 8 bytes
> >> for good_stuff'size use 96;    -- 12 bytes
>
> >> First, does the discriminant take up any size in the record?
>
> > In "stuff", it almost certainly takes space.  If you have a procedure
> > with a parameter X of type "stuff", and that procedure looks at
> > X.Has_Extra, the procedure has to get that data from somewhere, and it
> > will almost certainly get it from some field in X.  The discriminant
> > *could* be passed as a separate parameter, but that would be atypical.
>
> > For your derived types, normal_stuff and good_stuff, whether the
> > discriminant takes space depends on the implementation.  If you didn't
> > put any rep clauses on those types, they would probably have the exact
> > same representation as "stuff" because then type conversions would be
> > implemented just as straight copy operations.  But eliminating the
> > space for the discriminant is also possible.  (By the way, you can't
> > put a rep clause on the derived type under certain circumstances---see
> > 13.1(10)).
>
> >> When I
> >> tried this with a tagged record, I was told that my placement at 0
> >> bytes off set classed with the tag.  That's no good.
>
> > Tagged records are a completely different animal, here.  First of all,
> > you cannot declare a type extension and rearrange any fields
> > (including discriminants) that existed in the parent type; you
> > couldn't get dispatching to work if you were allowed to rearrange
> > those fields.  You can only use a rep clause to rearrange new fields
> > in the type extension.  Second, you definitely can't move the tag to a
> > different place than in the parent type.  That would just blow
> > everything up.
>
> > Finally, although it's theoretically possible to have tags in
> > different places for two different (non-derived) tagged types, it
> > makes implementing the language a lot more difficult.  This is even
> > more true now that interface types have been introduced in Ada 2005.
> > (If you declare a root type Root_Type with a tag in a nonstandard
> > place, and then later "type Child is new Root_Type and Interface_Type
> > with...", then how is an operation on Interface_Type'Class going to
> > know where to find the tag if you give it a Child?)  So it is entirely
> > reasonable for a compiler to insist on the tag being in a set place
> > for every tagged type.
>
> > I don't know what you say this is "no good"---what are you trying to
> > accomplish?  Whatever it is, you're probably going about it wrong.
>
> >> Second, does the layout of normal_stuff look like I expect it would,
> >> that is, the same as stuff?
>
> > If the 'Size clause on Normal_Stuff is legal, then probably not.
> > Stuff has to have room for two integers, a float, and a Boolean; if
> > Integer'Size is at least 16 and Float'Size is at least 32, then
> > Stuff'Size will be larger than 64, which means that the only way
> > Normal_Stuff'Size could be legally 64 would be for the compiler to not
> > allocate space for some fields.  That may mean not allocating size for
> > Blah since it will never exist in a Normal_Stuff anyway.  But when the
> > compiler realizes it will need to rearrange fields, there's no telling
> > what it will do.
>
> > Even if Integer'Size is 16, it's entirely possible that the compiler
> > will allocate 32 bits for Foo and Bar to help with the machine's
> > alignment requirements.  If that's the case, and if it accepts "for
> > Normal_Stuff'Size use 64" as legal, it will need to rearrange things.
>
> > So the answer to your question is "maybe, maybe not".
>
> >> Does the good_stuff record have a complete rep spec?
>
> > I don't know what you mean by this.  The language doesn't require that
> > a rep spec specify every field.  If you don't, the compiler will put
> > the additional fields anywhere it feels like (and not necessarily in
> > the same place where they exist in a Stuff).  So this is a legal rep
> > spec.
>
> >                                        -- Adam
>
>

type A_Common_Part is
   record
      I : Integer;
      F : Float;
   end record;

type An_Input is
   record
      CP : A_Common_Part;
   end record;

type An_Output is
   record
      CP : A_Common_Part;
      C  : Character;
   end record;

Wouldn't that do?

Cheers
-- Martin

Re: Rep Specing Variant Records

[Robert Love]

On 2009-09-17 03:25:19 -0500, Martin <martin.dowie@btopenworld.com> said:

> On Sep 17, 3:39�am, Robert Love <rbl...@airmail.net> wrote:
>> First, thanks to all who answered my question.
>> 
>> My big concern about the presence of a discriminant in the derived type
>> is that I'm shipping the record out via ether net to a C client to
>> read. �The C program will not tolerate the extra discriminate.
>> 
>> I have two very similar layouts in the input and output data. �I had
>> hoped to use variant records to save me some typing and coding. �I now
>> believe I will have to have two complete records, one for input and one
>> for output that will have 80% common structure. �Oh, well, it's just
>> more typing.
>> 
>> On 2009-09-16 10:03:37 -0500, Adam Beneschan <a...@irvine.com> said:
>> 
>>> On Sep 15, 6:22�pm, R.B. Love <rbl...@airmail.net> wrote:
>>>> I want to understand how a variant record gets rep spec'd. �Let's sa
> y I
>>>> have a sample of my record:
>> 
>>>> type stuff(has_extra:boolean) is
>>>> record
>>>> � � foo: integer;
>>>> � � bar: integer;
>>>> � � case has_extra
>>>> � � � � when true =>
>>>> � � � � � � blah : float;
>>>> � � � � when false =>
>>>> � � � � � � null;
>>>> � � end case;
>>>> end record;
>> 
>>>> for stuff use
>>>> record
>>>> � � foo at 0 range 0..31;
>>>> � � bar at 4 range 0..31;
>>>> end;
>> 
>>>> type normal_stuff is new stuff(has_extra=>false);
>>>> type good_stuff is new stuff(has_extra=>true);
>> 
>>>> for good_stuff use
>>>> record
>>>> � � blah at 12 range 0..31;
>>>> end record;
>> 
>>>> for normal_stuff'size use 64; �-- 8 bytes
>>>> for good_stuff'size use 96; � �-- 12 bytes
>> 
>>>> First, does the discriminant take up any size in the record?
>> 
>>> In "stuff", it almost certainly takes space. �If you have a procedure
>>> with a parameter X of type "stuff", and that procedure looks at
>>> X.Has_Extra, the procedure has to get that data from somewhere, and it
>>> will almost certainly get it from some field in X. �The discriminant
>>> *could* be passed as a separate parameter, but that would be atypical.
>> 
>>> For your derived types, normal_stuff and good_stuff, whether the
>>> discriminant takes space depends on the implementation. �If you didn'
> t
>>> put any rep clauses on those types, they would probably have the exact
>>> same representation as "stuff" because then type conversions would be
>>> implemented just as straight copy operations. �But eliminating the
>>> space for the discriminant is also possible. �(By the way, you can't
>>> put a rep clause on the derived type under certain circumstances---see
>>> 13.1(10)).
>> 
>>>> When I
>>>> tried this with a tagged record, I was told that my placement at 0
>>>> bytes off set classed with the tag. �That's no good.
>> 
>>> Tagged records are a completely different animal, here. �First of all
> ,
>>> you cannot declare a type extension and rearrange any fields
>>> (including discriminants) that existed in the parent type; you
>>> couldn't get dispatching to work if you were allowed to rearrange
>>> those fields. �You can only use a rep clause to rearrange new fields
>>> in the type extension. �Second, you definitely can't move the tag to
> a
>>> different place than in the parent type. �That would just blow
>>> everything up.
>> 
>>> Finally, although it's theoretically possible to have tags in
>>> different places for two different (non-derived) tagged types, it
>>> makes implementing the language a lot more difficult. �This is even
>>> more true now that interface types have been introduced in Ada 2005.
>>> (If you declare a root type Root_Type with a tag in a nonstandard
>>> place, and then later "type Child is new Root_Type and Interface_Type
>>> with...", then how is an operation on Interface_Type'Class going to
>>> know where to find the tag if you give it a Child?) �So it is entirel
> y
>>> reasonable for a compiler to insist on the tag being in a set place
>>> for every tagged type.
>> 
>>> I don't know what you say this is "no good"---what are you trying to
>>> accomplish? �Whatever it is, you're probably going about it wrong.
>> 
>>>> Second, does the layout of normal_stuff look like I expect it would,
>>>> that is, the same as stuff?
>> 
>>> If the 'Size clause on Normal_Stuff is legal, then probably not.
>>> Stuff has to have room for two integers, a float, and a Boolean; if
>>> Integer'Size is at least 16 and Float'Size is at least 32, then
>>> Stuff'Size will be larger than 64, which means that the only way
>>> Normal_Stuff'Size could be legally 64 would be for the compiler to not
>>> allocate space for some fields. �That may mean not allocating size fo
> r
>>> Blah since it will never exist in a Normal_Stuff anyway. �But when th
> e
>>> compiler realizes it will need to rearrange fields, there's no telling
>>> what it will do.
>> 
>>> Even if Integer'Size is 16, it's entirely possible that the compiler
>>> will allocate 32 bits for Foo and Bar to help with the machine's
>>> alignment requirements. �If that's the case, and if it accepts "for
>>> Normal_Stuff'Size use 64" as legal, it will need to rearrange things.
>> 
>>> So the answer to your question is "maybe, maybe not".
>> 
>>>> Does the good_stuff record have a complete rep spec?
>> 
>>> I don't know what you mean by this. �The language doesn't require tha
> t
>>> a rep spec specify every field. �If you don't, the compiler will put
>>> the additional fields anywhere it feels like (and not necessarily in
>>> the same place where they exist in a Stuff). �So this is a legal rep
>>> spec.
>> 
>>> � � � � � � � � � � � � � � � � � �
>  � �-- Adam
>> 
>> 
> 
> type A_Common_Part is
>    record
>       I : Integer;
>       F : Float;
>    end record;
> 
> type An_Input is
>    record
>       CP : A_Common_Part;
>    end record;
> 
> type An_Output is
>    record
>       CP : A_Common_Part;
>       C  : Character;
>    end record;
> 
> Wouldn't that do?
> 
> Cheers
> -- Martin


Yes, it would.  I'm already compositing smaller records into the big 
input and output records.  A record for the electrical data, one for 
the navigation data etc.

This was really an chance for me to experiment with variant records, to 
look into a corner of the language I don't use.  I learned a lot

Re: Rep Specing Variant Records

[Randy Brukardt]

I don't like responding to ancient messages, but...

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:e70b8d9a-3868-4d09-b745-794674ea610a@m3g2000pri.googlegroups.com...
...
>Finally, although it's theoretically possible to have tags in
>different places for two different (non-derived) tagged types, it
>makes implementing the language a lot more difficult.  This is even
>more true now that interface types have been introduced in Ada 2005.
>(If you declare a root type Root_Type with a tag in a nonstandard
>place, and then later "type Child is new Root_Type and Interface_Type
>with...", then how is an operation on Interface_Type'Class going to
>know where to find the tag if you give it a Child?)  So it is entirely
>reasonable for a compiler to insist on the tag being in a set place
>for every tagged type.

This is wildly incorrect and I want to set the record straight. We were very 
concerned about this, since at least two existing Ada 95 compilers (IBM 
Rational and Janus/Ada) supported non-standard tag locations, and we didn't 
want to force those compilers to remove that capability (it seems likely 
that they have customers depending on it). So there are rules specifically 
added to eliminate the extra "difficulty implementing the language".

In particular, the case postulated above is allowed to be rejected by a 
compiler, on the basis of 13.1(13.1/2):
"A type_declaration is illegal if it has one or more progenitors, and a 
representation item applies to an ancestor, and this representation item 
conflicts with the representation of some other ancestor. The cases that 
cause conflicts are implementation defined." Note that in this case it is 
the type declaration of Child that can be illegal, not the representation 
clause on Root_Type. The AARM notes on 13.1(13.1/2) explain this further.

The result is that using non-default locations for tags is no more difficult 
to implement in Ada 2005 as it is in Ada 95.

                               Randy.