* Inheritance of representation aspects
@ 2013-02-03 16:27 Simon Wright
2013-02-04 17:32 ` Adam Beneschan
0 siblings, 1 reply; 4+ messages in thread
From: Simon Wright @ 2013-02-03 16:27 UTC (permalink / raw)
A question on Stack Overflow[1] asks about deriving from an unchecked
union. The questioner thinks that a derived type should also be
an unchecked union, but GNAT doesn't.
A demo is
package Union is
type Access_Kind is (Named, Indexed);
type Array_Type is array (0 .. 1) of Integer;
type Base (Kind : Access_Kind := Access_Kind'First) is record
case Kind is
when Named =>
X, Y : Integer;
when Indexed =>
S : Array_Type;
end case;
end record with
Unchecked_Union => True,
Convention => C_Pass_By_Copy;
-- A primitive operation, freezes Base.
procedure P (R : Base) is null;
-- Derived types should inherit both representation aspects, so
-- both these aspects should be confirming.
type Derived_1 is new Base with Unchecked_Union => True;
type Derived_2 is new Base with Convention => C_Pass_By_Copy;
-- This should fail (ARM 13.1(10)).
type Derived_3 is new Base with Unchecked_Union => False;
end Union;
Both Unchecked_Union and C_Pass_By_Copy are representation aspects, and
should therefore be inherited (I've given links at my SO answer[2]). So
the aspects specified for Derived_1 and Derived_2 should both be
confirming and therefore OK (?), while the aspect for Derived_3 should
be illegal by ARM 13.1(10).
With GNAT GPL 2012 and GCC 4.8.0 (r195682), Derived_1 and Derived_2 fail
(representation item appears too late) and Derived_3 doesn't raise an
error.
With GNAT GPL 2012, if I comment out Derived_1 and Derived_2, the
compilation is successful (with 4.8.0 I get a bug box, which is a
separate issue).
Am I correct that these aspects should be inherited?
[1]
http://stackoverflow.com/questions/14663316/derive-from-unchecked-union
[2]
http://stackoverflow.com/questions/14663316/derive-from-unchecked-union/14671548#14671548
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Inheritance of representation aspects
2013-02-03 16:27 Inheritance of representation aspects Simon Wright
@ 2013-02-04 17:32 ` Adam Beneschan
2013-02-04 18:23 ` Simon Wright
0 siblings, 1 reply; 4+ messages in thread
From: Adam Beneschan @ 2013-02-04 17:32 UTC (permalink / raw)
On Sunday, February 3, 2013 8:27:20 AM UTC-8, Simon Wright wrote:
> A question on Stack Overflow[1] asks about deriving from an unchecked
> union. The questioner thinks that a derived type should also be
> an unchecked union, but GNAT doesn't.
> A demo is
>
> package Union is
> type Access_Kind is (Named, Indexed);
> type Array_Type is array (0 .. 1) of Integer;
>
> type Base (Kind : Access_Kind := Access_Kind'First) is record
> case Kind is
> when Named =>
> X, Y : Integer;
> when Indexed =>
> S : Array_Type;
> end case;
> end record with
> Unchecked_Union => True,
> Convention => C_Pass_By_Copy;
>
> -- A primitive operation, freezes Base.
> procedure P (R : Base) is null;
>
> -- Derived types should inherit both representation aspects, so
> -- both these aspects should be confirming
> type Derived_1 is new Base with Unchecked_Union => True;
> type Derived_2 is new Base with Convention => C_Pass_By_Copy;
>
> -- This should fail (ARM 13.1(10)).
> type Derived_3 is new Base with Unchecked_Union => False;
>
> end Union;
>
> Both Unchecked_Union and C_Pass_By_Copy are representation aspects, and
> should therefore be inherited (I've given links at my SO answer[2]). So
> the aspects specified for Derived_1 and Derived_2 should both be
> confirming and therefore OK (?), while the aspect for Derived_3 should
> be illegal by ARM 13.1(10).
>
> With GNAT GPL 2012 and GCC 4.8.0 (r195682), Derived_1 and Derived_2 fail
> (representation item appears too late) and Derived_3 doesn't raise an
> error.
>
> With GNAT GPL 2012, if I comment out Derived_1 and Derived_2, the
> compilation is successful (with 4.8.0 I get a bug box, which is a
> separate issue).
>
> Am I correct that these aspects should be inherited?
You're right that they should be inherited (13.1(15)), and that the declaration of Derived_3 would be illegal.
I'm not clear that Derived_1 and Derived_2 are legal, however. The aspect clauses are confirming, but there's no blanket rule that confirming aspect clauses are always legal. The rule in 13.1(10) says
"For an untagged derived type, it is illegal to specify a type-related representation aspect if the parent type is a by-reference type, or has any user-defined primitive subprograms."
So it's illegal, period. There is no exception here for confirming aspect clauses.
-- Adam
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Inheritance of representation aspects
2013-02-04 17:32 ` Adam Beneschan
@ 2013-02-04 18:23 ` Simon Wright
2013-02-05 2:45 ` Randy Brukardt
0 siblings, 1 reply; 4+ messages in thread
From: Simon Wright @ 2013-02-04 18:23 UTC (permalink / raw)
Adam Beneschan <adam@irvine.com> writes:
> On Sunday, February 3, 2013 8:27:20 AM UTC-8, Simon Wright wrote:
>> A question on Stack Overflow[1] asks about deriving from an unchecked
>> union. The questioner thinks that a derived type should also be
>> an unchecked union, but GNAT doesn't.
>> A demo is
>>
>> package Union is
>> type Access_Kind is (Named, Indexed);
>> type Array_Type is array (0 .. 1) of Integer;
>>
>> type Base (Kind : Access_Kind := Access_Kind'First) is record
>> case Kind is
>> when Named =>
>> X, Y : Integer;
>> when Indexed =>
>> S : Array_Type;
>> end case;
>> end record with
>> Unchecked_Union => True,
>> Convention => C_Pass_By_Copy;
>>
>> -- A primitive operation, freezes Base.
>> procedure P (R : Base) is null;
>>
>> -- Derived types should inherit both representation aspects, so
>> -- both these aspects should be confirming
>> type Derived_1 is new Base with Unchecked_Union => True;
>> type Derived_2 is new Base with Convention => C_Pass_By_Copy;
>>
>> -- This should fail (ARM 13.1(10)).
>> type Derived_3 is new Base with Unchecked_Union => False;
>>
>> end Union;
>>
>> Both Unchecked_Union and C_Pass_By_Copy are representation aspects, and
>> should therefore be inherited (I've given links at my SO answer[2]). So
>> the aspects specified for Derived_1 and Derived_2 should both be
>> confirming and therefore OK (?), while the aspect for Derived_3 should
>> be illegal by ARM 13.1(10).
>>
>> With GNAT GPL 2012 and GCC 4.8.0 (r195682), Derived_1 and Derived_2 fail
>> (representation item appears too late) and Derived_3 doesn't raise an
>> error.
>>
>> With GNAT GPL 2012, if I comment out Derived_1 and Derived_2, the
>> compilation is successful (with 4.8.0 I get a bug box, which is a
>> separate issue).
>>
>> Am I correct that these aspects should be inherited?
>
> You're right that they should be inherited (13.1(15)), and that the
> declaration of Derived_3 would be illegal.
>
> I'm not clear that Derived_1 and Derived_2 are legal, however. The
> aspect clauses are confirming, but there's no blanket rule that
> confirming aspect clauses are always legal. The rule in 13.1(10) says
>
> "For an untagged derived type, it is illegal to specify a type-related
> representation aspect if the parent type is a by-reference type, or
> has any user-defined primitive subprograms."
>
> So it's illegal, period. There is no exception here for confirming
> aspect clauses.
Still, it's be nice for it to be legal (perhaps 13.1(18.2) could be
amended to say that a confirming aspect clause isn't "really" a
specification?! Simpler if (10) just said that
"For an untagged derived type, it is illegal to specify a
*non-confirming* type-related representation aspect if the parent type
is a by-reference type, or has any user-defined primitive
subprograms."
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Inheritance of representation aspects
2013-02-04 18:23 ` Simon Wright
@ 2013-02-05 2:45 ` Randy Brukardt
0 siblings, 0 replies; 4+ messages in thread
From: Randy Brukardt @ 2013-02-05 2:45 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:lyehgwrl96.fsf@pushface.org...
...
> Still, it's be nice for it to be legal (perhaps 13.1(18.2) could be
> amended to say that a confirming aspect clause isn't "really" a
> specification?! Simpler if (10) just said that
>
> "For an untagged derived type, it is illegal to specify a
> *non-confirming* type-related representation aspect if the parent type
> is a by-reference type, or has any user-defined primitive
> subprograms."
Since 13.1(10) long predates the notion of "confirming" rep. clause, it
doesn't surprise me. Personally, I'd much prefer if this rule didn't exist
(although it does eliminate some weird cases that we'd otherwise have to
deal with). It makes it virtually impossible to use an untagged derived type
for anything valuable (no representation changes unless there are no
operations -- in which case what is the point of supporting a representation
change). I've never gotten any traction on that, and I doubt that I ever
will, so mainly I think, forget about untagged derived types as a useless
appendage of the language. (It's not worth fixing this rule, as it still
won't allow anything useful other than silly test programs.)
Randy.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-05 2:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-03 16:27 Inheritance of representation aspects Simon Wright
2013-02-04 17:32 ` Adam Beneschan
2013-02-04 18:23 ` Simon Wright
2013-02-05 2:45 ` Randy Brukardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox