Version 1.1 of ai05s/ai05-0112-1.txt

Unformatted version of ai05s/ai05-0112-1.txt version 1.1
Other versions for file ai05s/ai05-0112-1.txt

!standard 13.1(8)          08-08-13 AI05-0112-1/01
!class binding interpretation 08-08-13
!status work item 08-08-13
!status received 08-06-21
!priority Low
!difficulty Easy
!qualifier Omission
!subject Names for anonymous aspects of representation
The aspect of representation specifed by a representation pragma is never anonymous.
Confirmation: if the Independent_Components aspect of representation is specfied for a tagged type, then that aspect is inherited by derived types.
(See Summary.)
Append to the end of 13.1(8):
Unless otherwise specified, the name of the aspect of representation specified by a representation pragma is the name of the pragma.
AARM note - append after 13.1(8):
A Volatile_Components pragma (see C.6), for example, specifies the Volatile_Components aspect of representation of its argument.
What is name of the aspect of representation specified by each of the pragmas Atomic, Atomic_Components, Volatile, Volatile_Components, Independent, and Independent_Components?
Before attempting to answer that question, consider why it is that anyone would care about the answer. What difference does it make?
RM 13.1(9)states:
If a representation item is given that directly specifies an aspect of an entity, then it is illegal to give another representation item that directly specifies the same aspect of the entity.
This clause is intended to prevent, for example, applying the same representation pragma twice to a given type.
In a case such as
type T is array (Character) of Float; pragma Pack (T); pragma Pack (T); -- illegal
the existing wording captures this intent because it is clear that the Packing aspect has been specified twice.
In a case such as
type T is array (Character) of Boolean; pragma Independent_Components (T); pragma Independent_Components (T); -- illegal?
the situation is not so clear. One might argue that the first Independent_Components pragma certainly (wave hands here) specifies some aspect of representation and that the second such pragma then specifes the same aspect again.
This seems intuitive, but it does not seem to follow from a strict reading of the existing wording.
Rather than trying to infer and/or invent rules about anonymous aspects of representation, it seems simpler to give them names.
The existing wording (13.1(15/1)) about inheritance of aspects of representation by derived types applies in both the tagged and the untagged cases.
In particular, this applies to the Independent_Components aspect of representation.
Assuming that a given implementation does not support independent addressibility within an 8-bit storage unit, this implies that the following examples must be rejected:
type Untagged_Parent is record Nibble1, Nibble2 : Integer range 0 .. 15; end record; pragma Independent_Components (Untagged_Parent);
type Untagged_Derived is new Untagged_Parent;
for Untagged_Derived use record -- illegal F1 at 0 range 0 .. 3; F2 at 0 range 4 .. 7; end record;
type Tagged_Parent is tagged null record; pragma Independent_Components (Tagged_Parent);
type Tagged_Derived is new Tagged_Parent with record Nibble1, Nibble2 : Integer range 0 .. 15; end record;
for Tagged_Derived use record -- illegal F1 at 64 range 0 .. 3; F2 at 64 range 4 .. 7; end record;
Similarly, this wording also applies to the Volatile and Atomic aspects of implementation.
--!corrigendum 13.1(8)
B-Tests for examples like these should be constructed.

From the minutes of the Venice ARG meeting:

Steve wonders whether Independent is an aspect of representation. Tucker thinks
that is an interesting question that we haven't considered. C.6(14) says that
these are representation pragmas. But we don't have names for these aspects
of representation; there should be sentences about that (Atomic*, Volatile*,
Independent*). Tucker suggests a separate AI to answer this question.
Steve Baird has the short stick. Also, we should decide if all of these
are inherited for tagged types. Independent_Components applies to extension
components of a descendant (not to the parent components).

Ed suggests that he was previously wrong; we don't want inheritance for these
pragmas. Having that would prevent giving later representation clauses.

Steve Baird worries that type T is new S; would potentially be different from the
parent without inheritance.

We cannot decide on how or whether these pragmas are inherited; Steve is
directed to write up what makes sense to him and we'll throw stones at his

[Editor's note: version /01 is Steve's solution.]



Questions? Ask the ACAA Technical Agent