!standard  13.1(0)                               12-03-15    AI05-0295-1/03
!standard   3.8(11)
!standard  9.10(1)
!standard  13.1(0.1/1)
!standard  13.1(8)
!standard  13.1(9.1/1)
!standard  13.1(10)
!standard  13.1(11)
!standard  13.1(12)
!standard  13.1(13/1)
!standard  13.1(13.1/2)
!standard  13.1(15/1)
!standard  13.1(15.1/1)
!standard  13.1(18.2/2)
!standard  13.1(20)
!standard  13.1(21)
!standard  13.1(22)
!standard  13.1(24/2)
!standard  13.1(25/2)
!standard  13.1(26/2)
!standard  13.1(27/2)
!standard  13.1(28/2)
!standard  13.1.1(0)
!class Amendment 12-02-15
!status Amendment 2012 12-02-15
!status ARG Approved 8-0-2  12-02-25
!status work item 12-02-15
!status received 12-01-12
!priority Medium
!difficulty Medium
!subject Improve presentation of aspects
!summary

The presentation of aspects in 13, 13.1, and elsewhere is improved. Many places
where "representation items" are talked about are replaced with "representation
aspects".

!proposal

The presentation of aspects and representation items is not ideal. In addition,
there are many rules that are written in terms of "representation items" which
are intended to apply to all uses of the associated representation aspect
(not specifically about a representation item).

See the details given in the Wording section.

!wording

Modify 3.8(11/3):
    A name that denotes any component, protected subprogram, or entry is
    allowed within {an aspect_specification, or within} an operational or
    representation item that occurs within the declaration of the
    composite type

Modify AARM 3.8(12.f):

    Inherited discriminants are not allowed to be denoted, except within
    representation items {and aspect_specifications}.

Replace part of 9.10(1/3):
    Otherwise, two nonoverlapping objects are independently
    addressable  except when they are both parts of a composite
    object for which a nonconfirming
    representation item is used to specify record layout,
    Component_Size, Pack, Atomic, or convention, in which case
    it is unspecified whether the parts are independently addressable.
with:
    Otherwise, two nonoverlapping objects are independently addressable
    except when they are both parts of one composite object for which a
    nonconfirming value is specified for any of the
    following representation aspects: Layout, Component_Size, Pack, Atomic,
    or Convention; in this case, it is unspecified whether the parts
    are independently addressable.

Modify AARM 9.10(1.d/3):
    Any {aspect_specification or} representation item which would prevent this
    from being true should be rejected, ...

Change the title of 13.1 to "Operational and Representation Aspects".

Replace 13.1(0.1/3) with:

   Two kinds of aspects of entities can be specified: representation
   aspects and operational aspects. Representation aspects affect how
   the types and other entities of the language are to be mapped onto
   the underlying machine. Operational aspects determine other properties
   of entities.

   Either kind of aspect of an entity may be specified by means of an
   aspect_specification (see 13.1.1), which is an optional element of most
   kinds of declarations and applies to the entity or entities being declared.
   Aspects may also be specified by certain other constructs occurring
   subsequent to the declaration of the affected entity: a representation aspect
   value may be specified by means of a representation item and an
   operational aspect value may be specified by means of an operational item.

Replace AARM 13.1(1.a) with:

    Confirming the value of an aspect should never change the semantics
    of the aspect.

In 13.1(8/3), delete:

    Unless otherwise specified, the name of the aspect of representation
    specified by a representation pragma is the name of the pragma.

[There are two problems with this rule:
   1) It only applies to representation pragmas, so it doesn't apply to at
      least 9 pragmas which specify aspect values but are not representation
      pragmas (e.g., Inline).
   2) We don't use this rule. Every pragma that specifies an aspect
      explicitly states the name of the aspect as part of the definition
      of the semantics of the pragma.]

Also, replace "an *aspect of representation*" with "a *representation aspect*".

Replace 13.1 (9.2/3) with:

"Unless otherwise specified, it is illegal to specify an operational or
representation aspect of a generic formal parameter".

[Note that this is slightly redundant with 13.1.1(17/3), but as that is a
laundry list of places, it doesn't make sense to change it. And the rule
here is needed to apply to operational and representation items. We could
just leave this alone, but that then is misleading (since it applies to all
methods of specifying aspects.]

Modify 13.1(10):

For an untagged derived type, {it is illegal to specify a}[no] type-related
representation {aspect}[items are allowed] if the parent type is a by-reference
type, or has any user-defined primitive subprograms.

Update the AARM notes 13.1(10.a/1) and 13.1(10.b/3).

Modify 13.1(11/2):

... {Specification of a}[A] type-related representation {aspect}[item] is not
allowed for a descendant of a generic formal untagged type.

Update the AARM notes 13.1(11.a/1) and 13.1(11.b).

Modify 13.1(12):

{The specification of}[A representation item that specifies] the Size {aspect}
for a given subtype, or the size or storage place for an object (including a
component) of a given subtype, shall allow for enough storage space to
accommodate any value of the subtype.

Modify 13.1(13/1):

{If a specification of a}[A] representation or operational {aspect}[item that]
is not supported by the implementation{, it} is illegal[,] or raises an
exception at run time.

Modify 13.1(13.1/2):

A type_declaration is illegal if it has one or more progenitors, and
a {nonconfirming value was specified for a} representation {aspect of}[item
applies to] an ancestor, and this representation {aspect}[item] conflicts with the
representation of some other ancestor. The cases that cause conflicts are
implementation defined.

[Jeff asked: Would the simpler "A type_declaration is illegal if it has one or
more progenitors, and there is a conflict between the representation aspects of
the ancestors" be ok?  (Ancestors presumably including self).

Answer: No. The existing wording was carefully crafted so that implementations
cannot reject declarations unless some nonconfirming representation is
specified somewhere. The simpler wording would allow any combination of types to
be rejected if the implementation felt like it (since "conflicts" is
implementation defined). Note that I did simplify the wording a bit, and brought
in "nonconfirming". - Editor.]

In AARM 13.1(14.a), replace
   Note that it is illegal to specify an aspect (including a
   subtype-specific one) for a nonfirst subtype.
with:
   Note that most aspects (including the subtype-specific aspects Size
   and Alignment) may not be specified for a nonfirst subtype.
   The only language-defined exceptions to this rule are the
   Static_Predicate and Dynamic_Predicate aspects.

Modify 13.1(15/3):

    An inherited [aspect of] representation {aspect} is overridden by
    a subsequent {aspect_specification or} representation item that

Modify AARM 13.1(15.b.1):

    If an inherited aspect is confirmed by {an aspect_specification or by}
    a later representation item ...

    ... Thus the derived type has both a specified confirming and an inherited
    nonconfirming representation {value}[item]...

Modify 13.1(15.1/3):

     ...directly specified by {aspect_specifications or}
     operational items that are visible ...

     ... An inherited operational aspect is overridden by a subsequent
     {aspect_specification or} operational item that
     specifies the same aspect of the type.


Modify AARM 13.1(18.a/1):

    Note that {specifying a } representation {aspect}[items] can affect
    the semantics of the entity.

Replace 13.1(18.2/2):
   A representation item that specifies an aspect of representation that
   would have been chosen in the absence of the representation item is said
   to be *confirming*.
with:
   An aspect_specification or representation item that specifies a
   representation aspect that would have been chosen in the absence of the
   aspect_specification or representation item is said to be *confirming*. The
   aspect value specified in this case is said to be a
   *confirming* representation aspect value. Other values of the aspect
   are said to be *nonconfirming*, as are the @fa<aspect_specification>s and
   representation items that specified them.

[Editor: I added the part about "nonconfirming". We use this enough in the
Standard and notes that it seems good to have a definition somewhere, else
someone searching for it may never find it (especially now that we dropped
the hyphens).

It's odd that we specify this only for representation aspects. What about
operational aspects? Perhaps we never use the term for them.]

Modify 13.1(20):

An implementation may interpret [aspects of] representation {aspects} in an
implementation-defined manner. An implementation may place
implementation-defined restrictions on {the specification of} representation
{aspects}[items]. A *recommended level of support* is {defined}[specified] for
{the specification of} representation {aspects}[items] and related features in
each subclause. These recommendations are changed to requirements for
implementations that support the Systems Programming Annex (see C.2, "Required
Representation Support").

Modify AARM 13.1(20.a):
   Implementation defined: The interpretation of each [aspect of] representation
   {aspect}.

Modify AARM 13.1(20.b):
   Implementation defined: Any restrictions placed upon
   {the specification of} representation {aspects}[items].

Modify 13.1(21):
   The recommended level of support for {the specification of}
   all representation {aspects}[items] is qualified as follows:

Modify 13.1(21.1/2):

   A confirming {specification for a} representation {aspect}[item]
   should be supported.

Modify AARM 13.1(21.a.1/2): [and drop the .1 from the number, it's not needed]

   ... representation {aspect value}[item] ...

Modify 13.1(22):

An implementation need not support {the specification for a} representation
{aspect that contains}[items containing]
nonstatic expressions, {unless}[except that an
implementation should support a
representation item for a given entity if] each nonstatic expression [in
the representation item] is a name that statically denotes a constant
declared before the entity.

Modify 13.1(24/2), 13.1(25/2), and 13.1(26/2):

    An implementation need not support {specifying}
    a nonconfirming representation {aspect value}[item]
    if it could cause ...

Modify 13.1(27/2):

    An implementation need not support {specifying}
    a nonconfirming subtype-specific representation
    {aspect value for}[item specifying an aspect of representation of]
    an indefinite or abstract subtype.

Modify 13.1(28/2):
     For purposes of these rules, the determination of whether
     {specifying} a representation {aspect value for}[item applied to]
     a type...


Move clause 13.3.1 to 13.1.1.


!corrigendum 3.8(11)

@drepl
@xbullet<A @fa<name> that denotes any component, protected subprogram, or entry
is allowed within a representation item that occurs within the declaration of
the composite type.>
@dby
@xbullet<A @fa<name> that denotes any component, protected subprogram, or entry
is allowed within an @fa<aspect_specification>, an operational item, or a
representation item that occurs within the declaration of the composite type.>

!corrigendum 9.10(1)

@drepl
If two different objects, including nonoverlapping parts of the same
object, are @i<independently addressable>, they can be manipulated
concurrently by two different tasks without synchronization. Normally,
any two nonoverlapping objects are independently addressable. However,
if packing, record layout, or Component_Size is specified for a given
composite object, then it is implementation defined whether or not two
nonoverlapping parts of that composite object are independently
addressable.
@dby
If two different objects, including nonoverlapping parts of the same
object, are @i<independently addressable>, they can be manipulated
concurrently by two different tasks without synchronization.
Any two nonoverlapping objects are independently addressable if
either object is specified as independently addressable (see C.6). Otherwise,
two nonoverlapping objects are independently addressable
except when they are both parts of a composite object for which
a nonconfirming value is specified for any of the following representation
aspects: (record) Layout, Component_Size, Pack, Atomic, or Convention; in
this case it is unspecified whether the parts are independently addressable.

!corrigendum 13.1(0)

@drepl
Operational and Representation Items
@dby
Operational and Representation Aspects

!corrigendum 13.1(0.1/1)

@drepl
Representation and operational items can
be used to specify aspects of entities. Two kinds of aspects of entities can be
specified: aspects of representation and operational aspects. Representation
items specify how the types and other entities of the language are to be mapped
onto the underlying machine. Operational items specify other properties of
entities.
@dby
Two kinds of aspects of entities can be specified: representation
aspects and operational aspects. Representation aspects affect how
the types and other entities of the language are to be mapped onto
the underlying machine. Operational aspects determine other properties
of entities.

Either kind of aspect of an entity may be specified by means of an
aspect_specification (see 13.1.1), which is an optional element of most
kinds of declarations and applies to the entity or entities being declared.
Aspects may also be specified by certain other constructs occurring
subsequent to the declaration of the affected entity: a representation
aspect value may be specified by means of a representation
item and an operational aspect value may be specified by either an
operational item or a pragma.

!corrigendum 13.1(8)

@drepl
A representation item @i<directly specifies> an @i<aspect of representation> of
the entity denoted by the @fa<local_name>, except in the case of a type-related
representation item, whose @fa<local_name> shall denote a first subtype, and
which directly specifies an aspect of the subtype's type. A representation item
that names a subtype is either @i<subtype-specific> (Size and Alignment clauses)
or @i<type-related> (all others). Subtype-specific aspects may differ for
different subtypes of the same type.
@dby
A representation item @i<directly specifies> a @i<representation aspect> of
the entity denoted by the @fa<local_name>, except in the case of a type-related
representation item, whose @fa<local_name> shall denote a first subtype, and
which directly specifies an aspect of the subtype's type. A representation item
that names a subtype is either @i<subtype-specific> (Size and Alignment clauses)
or @i<type-related> (all others). Subtype-specific aspects may differ for
different subtypes of the same type.


!corrigendum 13.1(9.1/1)

@dinsa
An operational item that directly specifies an aspect of a type shall appear before
the type is frozen (see 13.14). If an operational item is given that directly
specifies an aspect of a type, then it is illegal to give another operational item
that directly specifies the same aspect of the type.
@dinst
Unless otherwise specified, it is illegal to specify an operational or
representation aspect of a generic formal parameter.

!corrigendum 13.1(10)

@drepl
For an untagged derived type, no type-related representation items are allowed
if the parent type is a by-reference type, or has any user-defined primitive
subprograms.
@dby
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.

!corrigendum 13.1(11)

@drepl
Operational and representation aspects of a generic formal parameter are the
same as those of the actual. Operational and representation aspects
are the same for all views of a type. A type-related representation item is not
allowed for a descendant of a generic formal untagged type.
@dby
Operational and representation aspects of a generic formal parameter are the
same as those of the actual. Operational and representation aspects
are the same for all views of a type. Specification of a type-related
representation aspect is not allowed for a descendant of a generic formal
untagged type.

!corrigendum  13.1(12)

@drepl
A representation item that specifies the Size for a given subtype, or the size
or storage place for an object (including a component) of a given subtype, shall
allow for enough storage space to accommodate any value of the subtype.
@dby
The specification of the Size aspect
for a given subtype, or the size or storage place for an object (including a
component) of a given subtype, shall allow for enough storage space to
accommodate any value of the subtype.

!corrigendum  13.1(13/1)

@drepl
A representation or operational item that is not supported by the implementation
is illegal, or raises an exception at run time.
@dby
If a specification of a representation or operational aspect is not supported by
the implementation, it is illegal or raises an exception at run time.

!corrigendum  13.1(13.1/2)

@drepl
A @fa<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.
@dby
A @fa<type_declaration> is illegal if it has one or more progenitors, and
a nonconfirming value was specified for a representation aspect of an ancestor,
and this conflicts with the representation of some other ancestor. The cases
that cause conflicts are implementation defined.

!corrigendum 13.1(15/1)

@drepl
A derived type inherits each type-related aspect of representation of its
parent type that was directly specified before the declaration of the derived
type, or (in the case where the parent is derived) that was inherited by the
parent type from the grandparent type. A derived subtype inherits each
subtype-specific aspect of representation of its parent subtype that was
directly specified before the declaration of the derived type, or (in the
case where the parent is derived) that was inherited by the parent subtype
from the grandparent subtype, but only if the parent subtype statically
matches the first subtype of the parent type. An inherited aspect of
representation is overridden by a subsequent representation item that
specifies the same aspect of the type or subtype.
@dby
A derived type inherits each type-related representation aspect of its
parent type that was directly specified before the declaration of the derived
type, or (in the case where the parent is derived) that was inherited by the
parent type from the grandparent type. A derived subtype inherits each
subtype-specific representation aspect of its parent subtype that was
directly specified before the declaration of the derived type, or (in the
case where the parent is derived) that was inherited by the parent subtype
from the grandparent subtype, but only if the parent subtype statically
matches the first subtype of the parent type. An inherited
representation aspect is overridden by a subsequent @fa<aspect_specification>
or representation item that specifies a different value for the same aspect of
the type or subtype.

!corrigendum 13.1(15.1/1)

@drepl
In contrast, whether operational aspects are inherited by an untagged derived
type depends on each specific aspect. Operational aspects are never inherited
for a tagged type. When operational aspects are inherited by an untagged
derived type, aspects that were directly specified by operational items that
are visible at the point of the derived type declaration, or (in the case
where the parent is derived) that were inherited by the
parent type from the grandparent type are inherited. An inherited operational
aspect is overridden by a subsequent operational item that specifies the same
aspect of the type.
@dby
In contrast, whether operational aspects are inherited by a derived type
depends on each specific aspect; unless specified, an operational aspect is
not inherited. When operational aspects are inherited by a derived type,
aspects that were directly specified by @fa<aspect_specification>s or
operational items that are visible at the point of the derived type declaration,
or (in the case where the parent is derived) that were inherited by the parent
type from the grandparent type are inherited. An inherited operational aspect is
overridden by a subsequent @fa<aspect_specification> or operational item that
specifies the same aspect of the type.


!corrigedum 13.1(18.2/2)

@drepl
A representation item that specifies an aspect of representation that
would have been chosen in the absence of the representation item is said
to be @i<confirming>.
@dby
An @fa<aspect_specification> or representation item that specifies a
representation aspect that would have been chosen in the absence of the
@fa<aspect_specification> or representation item is said to be @i<confirming>.
The aspect value specified in this case is said to be a
@i<confirming> representation aspect value. Other values of the aspect
are said to be @i<nonconfirming>, as are the @fa<aspect_specification>s or
representation items that specified them.

!corrigendum 13.1(20)

@drepl
An implementation may interpret aspects of representation in an
implementation-defined manner. An implementation may place
implementation-defined restrictions on representation items. A
@i<recommended level of support> is specified for representation items
and related features in each subclause. These recommendations are changed to
requirements for implementations that support the Systems Programming Annex (see
C.2, "Required Representation Support").
@dby
An implementation may interpret representation aspects in an
implementation-defined manner. An implementation may place
implementation-defined restrictions on the specification of representation
aspects. A @i<recommended level of support> is defined for
the specification of representation aspects and related features in
each subclause. These recommendations are changed to requirements for
implementations that support the Systems Programming Annex (see C.2, "Required
Representation Support").

!corrigendum 13.1(21)

@drepl
The recommended level of support for all representation items is qualified as
follows:
@dby
The recommended level of support for the specification of
all representation aspects is qualified as follows:

!corrigendum 13.1(21.1/2)

@drepl
@xbullet<A confirming representation item should be supported.>
@dby
@xbullet<A confirming specification for a representation aspect
should be supported.>

!corrigendum 13.1(22)

@drepl
@xbullet<An implementation need not support representation items containing
nonstatic expressions, except that an implementation should support a
representation item for a given entity if each nonstatic expression in the
representation item is a name that statically denotes a constant declared before
the entity.>
@dby
@xbullet<An implementation need not support the specification for a representation
aspect that contains nonstatic expressions, unless each nonstatic expression
is a @fa<name> that statically denotes a constant declared before the entity.>

!corrigendum 13.1(24/2)

@drepl
@xbullet<An implementation need not support a nonconfirming representation item
if it could cause an aliased object or an object of a by-reference type to be
allocated at a nonaddressable location or, when the alignment attribute of the
subtype of such an object is nonzero, at an address that is not an integral
multiple of that alignment.>
@dby
@xbullet<An implementation need not support specifying a nonconfirming
representation aspect value
if it could cause an aliased object or an object of a by-reference type to be
allocated at a nonaddressable location or, when the alignment attribute of the
subtype of such an object is nonzero, at an address that is not an integral
multiple of that alignment.>

!corrigendum 13.1(25/2)

@drepl
@xbullet<An implementation need not support a nonconfirming representation item
if it could cause an aliased object of an elementary type to have a size other
than that which would have been chosen by default.>
@dby
@xbullet<An implementation need not support specifying a nonconfirming
representation aspect value
if it could cause an aliased object of an elementary type to have a size other
than that which would have been chosen by default.>

!corrigendum 13.1(26/2)

@drepl
@xbullet<An implementation need not support a nonconfirming representation item
if it could cause an aliased object of a composite type, or an object whose
type is by-reference, to have a size smaller than that which would have been
chosen by default.>
@dby
@xbullet<An implementation need not support specifying a nonconfirming
representation aspect value
if it could cause an aliased object of a composite type, or an object whose
type is by-reference, to have a size smaller than that which would have been
chosen by default.>

!corrigendum 13.1(27/2)

@drepl
@xbullet<An implementation need not support a nonconfirming subtype-specific
representation item specifying an aspect of representation of an indefinite or
abstract subtype.>
@dby
@xbullet<An implementation need not support specifying a nonconfirming
subtype-specific representation aspect value for an indefinite or
abstract subtype.>

!corrigendum 13.1(28/2)

@drepl
For purposes of these rules, the determination of whether a representation item
applied to a type @i<could cause> an object to have some property is based
solely on the properties of the type itself, not on any available information
about how the type is used. In particular, it presumes that minimally aligned
objects of this type might be declared at some point.
@dby
For purposes of these rules, the determination of whether specifying
a representation aspect value for
a type @i<could cause> an object to have some property is based
solely on the properties of the type itself, not on any available information
about how the type is used. In particular, it presumes that minimally aligned
objects of this type might be declared at some point.


!corrigendum 13.1.1(0)

@dinsc

Force a conflict; the real text is found in the conflict file.


!discussion

How an aspect is specified should be irrelevant for most rules. Thus we
try to talk about aspects rather than items as much as possible.

!ACATS Test

No additional tests needed, this is mostly a presentation change (in some
cases, the semantics change, but only to reflect the intent that the rules
be the same for a representation aspect no matter how it is specified).

!ASIS

No change needed.

!appendix

From: Randy Brukardt
Sent: Friday, January 12, 2012  11:41 PM

Steve's review starts with:

> In some cases where representation items are disallowed, it looks like
> a similar ban on aspect specifications needs to be added:
>
> 13.1(9) says
>    Unless otherwise specified, an operational or representation
>    item shall not specify an aspect of a generic formal parameter.
>
> 13.1(10) says
>    For an untagged derived type, no type-related representation items
>    are allowed if the parent type is a by-reference type, or has any
>    user-defined primitive subprograms.
>
> These rules need to be extended to handle aspect specifications.

I wrote a lengthy reply, but eventually realized that I'm not sure how to
proceed.

For the first paragraph, we already have 13.3.1(17/3) [this is the "Denver"
version, not in draft 14, but there was something similar in draft 14]:

There are no language-defined aspects that may be specified on a
renaming_declaration, a generic_formal_parameter_declaration, a subunit, a
package_body, a task_body, a protected_body, or a body_stub other than a
subprogram_body_stub.

As this is a Legality Rule, I don't see anything not covered.

For the second, we do need to say something. But I suspect that there are many
more such rules. For instance, the last sentence of 13.1(11/2) says: "A
type-related representation item is not allowed for a descendant of a generic
formal untagged type."

13.1(12) says: "A representation item that specifies the Size for a given
subtype, or the size or storage place for an object (including a component) of a
given subtype, shall allow for enough storage space to accommodate any value of
the subtype."

I suspect that 90% of the rules that talk about "representation items" or
"operational items" also apply to the similar aspect (and other aspects in the
appropriate classes, as well). There are a few that clearly don't (for instance,
13.1(9/3), 13.1(9.1/3), since aspect_specifications have their own freezing
rules, and of course 13.1(5/1), because aspect_specifications have their own
name resolution rules, too).

Probably the best overall solution is to check every use of "representation
item" or "operational item" and change "item" to "aspect" if it applies to
aspects. But that looks like a lot of work, because many of these rules would
need rewording in that case.

We could also try a blanket rule saying that when we say "representation item"
we mean "representation aspect", but that would cause problems for the few rules
that are really only about items.

So I'm not sure about the best course of action.

---------------------

If we were to try the "best solution", we'd have to do rewording like: (I
started at the beginning of 13.1, and worked forward)

[Note: 13.1(8/3) and 13.1(8.1/3) are covered by 13.3.1(23-27/3). There is a bit
of a disconnect between "subtype-specific" and "view-specific" here, but as
there already is a TBH in 13.1(8.a), I think we can ignore that.

13.1(9.2/3) is already covered, as noted above.]

Modify 13.1(10):

For an untagged derived type, {it is illegal to specify an}[no] type-related
representation {aspect}[items are allowed] if the parent type is a by-reference
type, or has any user-defined primitive subprograms."

Modify 13.1(11/2):

... {Specification of a}[A] type-related representation {aspect}[item] is not
allowed for a descendant of a generic formal untagged type.

Modify 13.1(12):

{The specification of}[A representation item that specifies] the Size {aspect}
for a given subtype, or the size or storage place for an object (including a
component) of a given subtype, shall allow for enough storage space to
accommodate any value of the subtype.

Modify 13.1(13/1):

{Specifying a}[A] representation or operational {aspect such}[item] that {the
aspect} is not supported by the implementation is illegal, or raises an
exception at run time.

Modify 13.1(13.1/2):

A type_declaration is illegal if it has one or more progenitors, and a
representation item {or aspect_specification} applies to an ancestor, and this
representation item {or aspect_specification} conflicts with the representation
of some other ancestor. The cases that cause conflicts are implementation
defined.

[Note: 13.1(15/3, 15.1/3) don't need modification, because an aspect_specification
cannot occur after the declaration of the entity.]

Modify 13.1(18.2/2):

A representation item {or aspect_specification} that specifies an aspect of
representation that would have been chosen in the absence of the representation
item is said to be confirming.

Modify 13.1(20):

.... An implementation may place implementation-defined restrictions on {the
specification of} representation {aspects}[items].

------------

I stopped here, as this is enough to give a flavor of the approach. Is this the
right approach to the problem? Or is there something simpler?

****************************************************************

From: Tucker Taft
Sent: Friday, January 13, 2012  8:57 AM

Painful as it is, I think we should probably try to do this.
We need a volunteer.  Oh yes, who identified the problem? ;-)

****************************************************************

From: Steve Baird
Sent: Friday, January 13, 2012  11:38 AM

If we decide that we want to go with this approach (which seems like a good
choice to me), then I'll try to come up with some wording.

We seem to be approaching consensus (3 in favor, 0 against), but we're not there
yet.

Other folks?

****************************************************************

From: Randy Brukardt
Sent: Friday, January 13, 2012  1:42 PM

Well, as usual, they're preoccupied with the easy questions that aren't
important (wording a rule about something that goes without saying) and can't be
bothered to have an opinion on something reasonably important (making sure that
the rules that we mean to apply to representation aspects actually do apply to
representation aspects). My guess is that you'll have a long wait before anyone
else weights in - please don't wait too long to do the wording. I always end up
having to guess on the tough questions. Grump.

****************************************************************

From: Bob Duff
Sent: Friday, January 13, 2012  2:16 PM

> Well, as usual, they're preoccupied with the easy questions that
> aren't important...

I am preoccupied with doing my RM/AARM review.  I've saved up some emails, and
plan to understand and perhaps answer them -- hopefully this weekend.

****************************************************************

From: Brad Moore
Sent: Friday, January 13, 2012  3:10 PM

> ... My guess is that you'll have a long wait before anyone else
> weights in - please don't wait too long to do the wording. I
> always end up having to guess on the tough questions. Grump.

Maybe not so long after all. ;-)

I think the changes are needed, and wording as suggested in the flavor of
Randy's initial email would be a worthwhile improvement, even if it will be a
bit painful to make all the changes.

****************************************************************

From: Gary Dismukes
Sent: Friday, January 13, 2012  3:22 PM

> We seem to be approaching consensus (3 in favor, 0 against), but we're
> not there yet.
>
> Other folks?

I'm also in favor of the approach that Randy suggested.

****************************************************************

From: Steve Baird
Sent: Friday, January 13, 2012  5:07 PM

> We could also try a blanket rule saying that when we say
> "representation item" we mean "representation aspect", but that would
> cause problems for the few rules that are really only about items.
>

This approach has the problems that Randy pointed out.

However, we could define some new term to denote the union of "representation
item" and "aspect specification which specifies an aspect of representation".

For example, in 9.10(1/3), we've got

   Otherwise, two nonoverlapping objects are independently addressable
   except when they are both parts of a composite object for which a
   nonconfirming representation item is used to specify ...

It would be nice if this could be updated by just replacing
   "representation item"
with some new term.

Would it be too confusing to use the term "representation specification"?

The above wording would then read

   Otherwise, two nonoverlapping objects are independently addressable
   except when they are both parts of a composite object for which a
   non-confirming representation specification is used to specify ...

If that term seems like it comes with too much baggage, perhaps "aspect
specifier"? I don't much like defining "aspect specification" (with or without
the underscore) and "aspect specifier" as two subtly-different things.

Suggestions?

****************************************************************

From: Tucker Taft
Sent: Friday, January 13, 2012  5:14 PM

How about representation specification? (<grin> for those who knew and loved Ada
83)  "We Want Rep Specs Back!"

****************************************************************

From: Randy Brukardt
Sent: Friday, January 13, 2012  5:25 PM

> Suggestions?

I don't think "aspect specifier" works, because whatever the term is, it has to
include "representation" (and remember, there also needs to be a similar term
for "operational item"). We defintely don't want "aspect specification" and
"aspect_specification" to mean different things.

"representation specification" is indeed the best term that I can come up with,
but I agree that it has baggage (even if it hasn't been used officially since
1994).

That's why I rejected this approach when I reworded some of these rules.

The best approach is simply to talk about the aspect; no one (ought to) care
*how* it gets specified. This doesn't always work, but when it does it is the
best:

   Otherwise, two nonoverlapping objects are independently addressable
   except when they are both parts of a composite object for which a
   non-confirming representation value is specified for [list of aspects]...

When we do need to talk about the item, I think the long approach is best; just
mention both ways and be done with it. Hopefully that isn't needed very often.

****************************************************************

From: Steve Baird
Sent: Friday, January 13, 2012  5:30 PM

Sounds right.
I'll try that approach.

****************************************************************

From: Randy Brukardt
Sent: Friday, January 13, 2012  6:37 PM

Note that you'll need to define "non-confirming representation aspect value" or
something like that. (That's where I stopped last night; looked messy.) That's
probably a better idea anyway, because it decouples "how" and "what".

****************************************************************

From: Randy Brukardt
Sent: Monday, January 16, 2012  9:20 PM

Jeff Cousins opened his review of chapter 13 with the following:

> Most of the detail looks fine to me, so trying to stand back a bit,
> the structure of the opening few paragraphs looks a bit odd.
> I think that rather than in the section specific to Operational and
> Representation Items (13.1 0.1/3) saying that representation and
> operational aspects may also be specified in some other way, it would
> be better to say in the intro in section 13 1/1:
> what representation and operational aspects are (preferably something
> less vague than "other properties" for the latter); then that some may
> be specified by Operational and Representation Items (see 13.1) and
> some by Aspect Specifications (see 13.3.1).
>
> The term aspect specification would then be introduced before it is
> used (e.g. by 13.1 9/3).

This is probably a good idea. It seems related to the work Steve is doing, so I
recommend that we  give it off to him to propose a replacement for the 13 1/1
introduction (and possibly the 13.1 introduction as well, since we won't want to
repeat the text again).

As far as operational aspects being "other properties", please suggest something
better that covers stream attributes, external tag, and properties like
preelaborable initialization (along with properties yet to be invented). We
tried back in 1999 and pretty much decided that "anything else" was the best
description. The only real requirement is that they can be specified on a
private view (unlike representation aspects).

> In general through chapter 13 the emphasis should first be on what the
> representation and operational aspects are, then say what the
> mechanisms are for specifying them.

We decided many years ago that we wouldn't renumber the clauses, because so many
books, error messages, and the like depend on them. So we're pretty much stuck
with the existing order of presentation, even if it is not ideal. One thing we
may want to consider is moving 13.3.1 up to 13.1.1, since the idea of
aspect_specification is more general than the specific attributes that make up
the vast majority of 13.3.

But I don't think we can do much beyond a bit of cosmetic patching to the bulk
of 13.1. That means there is going to be a mixture of "representation aspects"
and "representation item" rules here.

To summarize, I'm suggesting:
(1) That we ask Steve to update the introductions of 13 and 13.1 along with the
    other work he is doing to generalize "representation items" to
    "representation aspects".
(2) We consider moving 13.3.1 (aspect_specifications) to 13.1.1, since it is the
    most important way to specify aspects in Ada 2012. It should come as soon as
    we can put it in without changing the text too much.

[Aside: Jeff also wonders why some of the text uses "aspect of representation",
and other text uses "representation aspect". The first term was introduced in
Ada 95, and is mainly used in Ada 95-era text; the other comes from later work
starting with Corrigendum 1 (where we introduced "operational aspect", since
"aspect of operational" doesn't make any sense). There is an argument to make
these all the same, but I'm not going to make it. I don't want to crush poor
Steve. :-)]

****************************************************************

From: Bob Duff
Sent: Tuesday, January 17, 2012  8:33 AM

> [Aside: Jeff also wonders why some of the text uses "aspect of
> representation", and other text uses "representation aspect". The
> first term was introduced in Ada 95, ...

Actually, it predates Ada 9X -- I got it from the Ada 83 RM.
13.1 says:

  The effect of the elaboration of a representation clause is to define
  the corresponding aspects of the representation.

>...and is mainly used in Ada 95-era text; the other  comes from later
>work starting with Corrigendum 1 (where we introduced  "operational
>aspect", since "aspect of operational" doesn't make any sense).
> There is an argument to make these all the same, but I'm not going to
>make  it. I don't want to crush poor Steve. :-)]

Yeah, if it ain't broke, don't fix it.

****************************************************************

From: Jeff Cousins
Sent: Wednesday, January 18, 2012  7:25 AM

I think it would make chapter 13 more coherent to standardise on "representation
aspect", it doesn't affect many places.

****************************************************************

From: Jeff Cousins
Sent: Wednesday, January 18, 2012  7:30 AM

> As far as operational aspects being "other properties", please suggest
> something better that covers stream attributes, external tag, and properties
> like preelaborable initialization (along with properties yet to be invented).
> We tried back in 1999 and pretty much decided that "anything else" was the
> best description. The only real requirement is that they can be specified on a
> private view (unlike representation aspects).

Couldn't it say "such as " then give your list above?  And add the bit about
private view as an AARM note?

****************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, January 17, 2012  1:08 AM

> An aspect_mark doesn't specify anything, it's just part of an
> aspect_specification. If we want to talk about anything, it's the
> unnamed "aspect_mark => aspect_definition" part of an
> aspect_specification, since that is what really does the specifying.
> Changing the syntax to give that a name (but what?) and then using that name here would work.

Aspect_Association seems in line with the rest of the language (and I think
we'll need that name for ASIS anyway)

****************************************************************

From: Jeff Cousins
Sent: Wednesday, January 18, 2012  7:16 AM

Thanks Jean-Pierre for that suggestion.  That would seem to fit, e.g. it's like
X => Y for a pragma association.

I think there might be several places in 13 which say aspect specification when
they really should say aspect association (or whatever term we decide on) as
they're talking about the setting of an individual aspect rather than the whole
syntax construct  "with <comma_separated_list>".

****************************************************************

From: Steve Baird
Sent: Thursday, January 26, 2012  6:39 PM

...
>> Probably the best overall solution is to check every use of
>> "representation item" or "operational item" and change "item" to
>> "aspect" if it applies to aspects. But that looks like a lot of work,
>> because many of these rules would need rewording in that case.
>>
...
> Painful as it is, I think we should probably try to do this.

I tried to follow this approach.
Results below.

------------------

I'm ignoring the "nonconfirming" vs. "non-confirming" issue and hoping that the
hyphen police have already straightened things out in some RM version later than
the one I am looking at.

I also have used "aspect_specification" throughout; it mey be that we want to
use "aspect specification" in some places.

====

3.8(11/3)
    A name that denotes any component, protected subprogram, or entry is
    allowed within an operational or representation item[, or within an
    aspect_specification,] that occurs within the declaration of the
    composite type

Is "occurs within" right here? Should that be something like "occurs within the
immediate scope"? Does a record layout rep clause "occur within" the record
declaration? It certainly does not textually.

====

3.8(12.f)

    Inherited discriminants are not allowed to be denoted, except within
    representation items [and aspect_specifications].

====

7.3(5)
It seems a bit odd that we have
   Similarly, before the full declaration, the name of the partial view
   cannot be used in ... a representation item.

but we syntactically allow a private_type_declaration to include an
aspect_specification.

Contrast this with the more consistent treatment of generic formal types.

For aspects we have (13.3.1(4.b/3))
    There are no language-defined aspects that may be specified
    on generic formals, but implementations might support some and 13.1(9.2/3) says
    Unless otherwise specified, an operational or representation item
    shall not specify an aspect of a generic formal parameter.

Probably insufficiently broken.

====

9.10(1/3)
    Otherwise, two nonoverlapping objects are independently
    addressable  except when they are both parts of a composite
    object for which a non-confirming
    representation item is used to specify record layout,
    Component_Size, Pack, Atomic, or convention, in which case
    it is unspecified whether the parts are independently addressable.
=>
    Otherwise, two nonoverlapping objects are independently addressable
    except when they are both parts of one composite object for which a
    non-confirming representation value is specified for any of the
    following aspects: Layout, Component_Size, Pack, Atomic,
    or Convention; in this case, it is unspecified whether the parts
    are independently addressable.

====

9.10(1.d/3)
    Any representation item [or aspect_specification] which would prevent this
    from being true should be rejected, ...

====

13.1(1.a)

    Confirming the value of an aspect with an operational or representation
    item[, or with a an aspect_specifcation,] should never change the semantics
    of the aspect.

Alternatively, this wording could be made shorter instead of longer:

    Confirming the value of an aspect should never change the semantics
    of the aspect.


====

Already covered in Randy's message, but I'll repeat here:

Modify 13.1(10)

For an untagged derived type, {it is illegal to specify an}[no] type-related
representation {aspect}[items are allowed] if the parent type is a by-reference
type, or has any user-defined primitive subprograms."

[Should we update the corresponding note 10.b/3]]

Modify 13.1(11/2)

... {Specification of a}[A] type-related representation {aspect}[item] is not
allowed for a descendant of a generic formal untagged type.

Modify 13.1(12)

{The specification of}[A representation item that specifies] the Size {aspect}
for a given subtype, or the size or storage place for an object (including a
component) of a given subtype, shall allow for enough storage space to
accommodate any value of the subtype.

Modify 13.1(13/1)

{Specifying a}[A] representation or operational {aspect such}[item] that {the
aspect} is not supported by the implementation is illegal, or raises an
exception at run time.

Modify 13.1(13.1/2)

A type_declaration is illegal if it has one or more progenitors, and a
representation item {or aspect_specification} applies to an ancestor, and this
representation item {or aspect_specification} conflicts with the representation
of some other ancestor. The cases that cause conflicts are implementation
defined.

Modify 13.1(18.2/2) [see below - I added to Randy's changes]

Modify 13.1(20)

.... An implementation may place implementation-defined restrictions on {the
specification of} representation {aspects}[items].

====

13.1(15/3)

    An inherited aspect of representation is overridden by
    [an aspect_specification or] a subsequent representation item that

====

13.1(15,b,1)

    If an inherited aspect is confirmed by [an aspect_specification or by]
    a later representation item ...

    Thus the derived type has both a specified confirming and an inherited
    non-confirming representation item [or aspect_specification] ...

====

13.1(18.a/1)

    Note that representation items [and aspect_specifications] can affect
    the semantics of the entity.

====

13.1(18.2/2)

Replace

   A representation item that specifies an aspect of representation that
   would have been chosen in the absence of the representation item is said
   to be confirming.

with

   A representation item or aspect_specification that specifies an aspect
   of representation that would have been chosen in the absence of the
   representation item is said  to be confirming. The aspect value specified
   in this case is said to be a confirming representation aspect value.

====

13.1(20)

    An implementation may place implementation-defined restrictions on
    representation items [and aspect_specifications].

    A recommended level of support is specified for representation items
    [, aspect_specifications,] and related features in each subclause

====

13.1(20.b)
   Implementation defined: Any restrictions placed upon representation items
   [and aspect_specifications].

====

13.1(21)
    The recommended level of support for all representation items
    [and aspect_specifications] is qualified as follows:

====

13.1(21.1/2)

   A confirming representation item [or aspect_specification]
   should be supported.

Modifying the 21.a.1/2 TBH note just seems too pedantic.

====

I think that we do not need to make any change to 13.1(22).
I also think this is not 100% obvious and should therefore be reviewed.

====

13.1(24/2), 13.1(25/2), and 13.1(26/2)

    An implementation need not support a nonconfirming representation item
    [or aspect_specification] if it could cause ...

====

13.1(27/2)

    An implementation need not support a nonconfirming subtype-specific
    representation item [or aspect_specification] ...

====

13.1(28/2)
     For purposes of these rules, the determination of whether a
     representation item [or aspect_specification] applied to a type


****************************************************************

From: Tucker Taft
Sent: Thursday, January 26, 2012  7:46 PM

> 3.8(11/3)
> A name that denotes any component, protected subprogram, or entry is
> allowed within an operational or representation item[, or within an
> aspect_specification,] that occurs within the declaration of the
> composite type ...

I am presuming you are using "[" "]"  to mean "insert" as opposed to its usual
meaning of "delete."

****************************************************************

From: Randy Brukardt
Sent: Thursday, January 26, 2012  9:56 PM

Like Tuck, I'm assuming that you are using [] to reflect insertions rather than
the usual {} ([] usually means deletions).

...
> 3.8(11/3)
>     A name that denotes any component, protected subprogram, or entry is
>     allowed within an operational or representation item[, or within an
>     aspect_specification,] that occurs within the declaration of the
>     composite type
>
> Is "occurs within" right here? Should that be something like "occurs
> within the immediate scope"? Does a record layout rep clause "occur
> within" the record declaration? It certainly does not textually.

But it does "occur within" the scope of the record declaration and it is
directly visible there, so I think this is OK (not ideal perhaps, but I fear
that tinkering could make it worse). In the absense of a suggestion...

...
> ====
>
> 7.3(5)
> It seems a bit odd that we have
>    Similarly, before the full declaration, the name of the partial view
>    cannot be used in ... a representation item.
>
> but we syntactically allow a private_type_declaration to include an
> aspect_specification.
>
> Contrast this with the more consistent treatment of generic formal types.

Yes, because operational aspects (and items) are allowed on partial views (along
with uncategorized aspects like type invariants). Whereas there aren't any
aspects at all that are allowed on formal types.

> For aspects we have (13.3.1(4.b/3))
>     There are no language-defined aspects that may be specified
>     on generic formals, but implementations might support some and
13.1(9.2/3) says
>     Unless otherwise specified, an operational or representation item
>     shall not specify an aspect of a generic formal parameter.
>
> Probably insufficiently broken.

It's not broken at all. "representation aspect" is a subset of all aspects. Not
all aspect_specifications specify representation aspects. (I hope you kept that
in mind in your wording, else a redo will be needed.)

...
> 13.1(1.a)
>
>     Confirming the value of an aspect with an operational or representation
>     item[, or with a an aspect_specifcation,] should never change the semantics
>     of the aspect.
>
> Alternatively, this wording could be made shorter instead of longer:
>
>     Confirming the value of an aspect should never change the semantics
>     of the aspect.

I don't see any rewrite of the introduction, as requested by Jeff Cousins in his
review and assigned to the one already rewriting this stuff. Nor any conclusion
on whether 13.3.1 should really be earlier in the Standard (probably as 13.1.1).

(I didn't look closely at most of the wording, figuring I'll do that when I
write the AI up.)

****************************************************************

From: Steve Baird
Sent: Friday, January 27, 2012  10:45 AM

> I am presuming you are using "[" "]"  to mean "insert" as opposed to
> its usual meaning of "delete."

Oops.
Right.

****************************************************************

From: Steve Baird
Sent: Friday, January 27, 2012  6:47 PM

After much helpful discussion with Randy, here is my attempt to patch up the
problems that Randy identified with the proposal that I sent yesterday.

These changes are in addition to the changes proposed yesterday.

   -- Steve

------------

13.1(01./3)
Existing text is:

   [Representation and operational items can be used to specify aspects
   of entities. Two kinds of aspects of entities can be specified:
   aspects of representation and operational aspects. Representation
   items specify how the types and other entities of the language are to
   be mapped onto the underlying machine. Operational items specify other
   properties of entities. In addition to representation and operational
   items, aspects of entities  may be specified using an
   aspect_specification (see 13.3.1), which is an
   optional element of certain kinds of declarations. ]

Replace this with:

   Two kinds of aspects of entities can be specified: representation
   aspects and operational aspects. Representation aspects affect how
   the types and other entities of the language are to be mapped onto
   the underlying machine. Operational aspects relate to other properties
   of entities.

   Either kind of aspect of an entity may be specified by means of an
   aspect_specification, which is an optional element of most kinds
   of declarations and applies to the entity or entities being declared.
   Aspects may also be specified by certain other constructs occurring
   subsequent to the declaration of the affected entity: a representation
   aspect value may be specified by means of a representation
   item and an operational aspect value may be specified by either an
   operational item or a pragma.


====

In 13.1(8/3), delete:

    Unless otherwise specified, the name of the aspect of representation
    specified by a representation pragma is the name of the pragma.

There are two problems with this rule:
   1) It only applies to representation pragmas, so it doesn't apply to at
      least 9 pragmas which specify aspect values but are not representation
      pragmas (e.g., Inline).
   2) We don't use this rule. Every pragma that specifies an aspect
      explicitly states the name of the aspect as part of the definition
      of the semantics of the pragma.

====

13.1(14.a)
Replace
   Note that it is illegal to specify an aspect (including a
   subtype-specific one) for a nonfirst subtype.

with
   Most aspects (including the subtype-specific aspects Size
   and Alignment) may not be specified for a nonfirst subtype.
   The only language-defined exceptions to this rule are the
   Static_Predicate and Dynamic_Predicate aspects.

====

Move 13.3.1 to 13.1.1

****************************************************************

From: Jeff Cousins
Sent: Thursday, February  2, 2012  4:46 AM

[A top post on the Jan 26th message from Steve:]

Thanks Steve.  These proposed changes are very much the sort of thing I was
after.

If aspect specifications are now the preferred method of specifying aspects I
think that they should be listed before operational or representation items;
this is done in a couple of places but most list the old method first.

Re 13.3.1 (34/3) versus 13.1 (9.2/3), the syntax in 12.3, 12.6 & 12.7 clearly
allows for aspect_specifications on generic formal parameters.  At work we've
had a recent problem about whether or not pragmas can apply to generic formal
parameters, so I think we should be a bit clearer about when
aspect_specifications are going to be allowed on generic formal parameters
(whenever they are, it seems like it's only going to be in exceptional cases). A
more detailed comment on 13.1 (9.2/3): should this now be "Unless otherwise
specified, it is illegal to specify an operational or representation aspect of a
generic formal parameter" i.e. talk about aspects not items.

13.1 (13.1/2) Would the simpler "A type_declaration is illegal if it has one or
more progenitors, and there is a conflict between the representation aspects of
the ancestors" be ok?  (Ancestors presumably including self).

13.1 (15.1/3) and 13.1 (18.2/2) If you're changing these anyway it would be nice
to replace "aspect of representation" by " representation aspect".

****************************************************************

From: Jeff Cousins
Sent: Thursday, February  2, 2012  4:59 AM

[A top post on the Jan 27th message from Steve:]

This is also very much the sort of change that I was after.  I was also
envisaging moving the 13.1 (0.1/3) text up to 13, if not doesn't the title of
13.1 need changing from "Operational and Representation Items" to "Operational
and Representation Aspects" (or even "Representation and Operational Aspects" as
they're usually, but not always, talked about in that order)?

****************************************************************

From: Steve Baird
Sent: Thursday, February  2, 2012  3:13 PM

> Thanks Steve.  These proposed changes are very much the sort of thing I was
> after.

Thank you for pointing out the need for these changes.

> If aspect specifications are now the preferred method of specifying
> aspects I think that they should be listed before operational or
> representation items; this is done in a couple of places but most list the
> old method first.

Could you be more specific? I could try to hunt these down, but it sounds like
you already have some examples in mind.

> Re 13.3.1 (34/3) versus 13.1 (9.2/3), the syntax in 12.3, 12.6 & 12.7 clearly allows for
> aspect_specifications on generic formal parameters.
> At work we've had a recent problem about whether or not pragmas can
> apply to generic formal parameters, so I think we should be a bit
> clearer about when aspect_specifications are going to be allowed on generic formal
> parameters (whenever they are, it seems like it's only going to be in exceptional cases).

I think it would be clearer if 13.3.1 (34/3) referred to all generic formal
parameters, not just formal types.

> A more detailed comment on 13.1 (9.2/3): should this now be "Unless
> otherwise specified, it is illegal to specify an operational or representation
> aspect of a generic formal parameter" i.e. talk about aspects not items.

I think that would only make sense if we unified the two paragraphs and
eliminated 13.3.1 (34/3); that, in turn, would only make sense if we expanded
13.1 (9.2/3) to handle renames as well:

Seems reasonable.to me.

Applying pragma Inline to a subprogram rename, for example, would be handled by
the "unless otherwise specified" clause.

> 13.1 (13.1/2) Would the simpler "A type_declaration is illegal if it
> has one or more progenitors, and there is a conflict between the epresentation
> aspects of the ancestors" be ok?  (Ancestors presumably including self).

There is no new Ada2012 wording there and the old wording is not sufficiently
broken to warrant any changes.

Yes, my review included a comment about the related AARM note (the one with
"It's hard to imagine .."), but I ended with "Probably insufficiently broken and
no action needed."

> 13.1 (15.1/3) and 13.1 (18.2/2) If you're changing these anyway it
> would be nice to replace "aspect of representation" by " representation
> aspect".

Good point. I agree.

>
> I was also envisaging moving the 13.1 (0.1/3) text up to 13,

Good point, I agree.
Just to be clear, we are talking here about the new proposed two-paragraph
replacement for 13.1 (0.1/3).

Thanks for all the good suggestions,

****************************************************************

From: Jeff Counsins
Sent: Monday, February  6, 2012  11:20 AM

> Could you be more specific? I could try to hunt these down, but it sounds like
> you already have some examples in mind.

It's not very important, but I was thinking of putting {with an aspect specification,
or } with an operational or representation item {,} rather than with an operational
or representation item{, or with an aspect specification, } e.g. 13.1 (1.a).

> I think it would be clearer if 13.3.1 (34/3) referred to all generic formal
> parameters, not just formal types.

Yes.

> Just to be clear, we are talking here about the new proposed two-paragraph
> replacement for 13.1 (0.1/3).

Yes.

****************************************************************

From: Randy Brukardt
Sent: Friday, February 17, 2012  2:54 AM

> > Just to be clear, we are talking here about the new
> proposed two-paragraph replacement for 13.1 (0.1/3).
>
> Yes.

I've looked at this, and I don't think it is a good idea. It would leave 13.1
starting with the discussion of the kinds of items, which is the wrong thing
that contains dozens of rules about aspects.

I've changed the title of 13.1 to "Operational and Representation Aspects" (I
don't want to change the order, because there was *some* reason we chose it in
the past, and it's a lot easier to just change the one word in the 100+
cross-references.) That should help your major complaint.

I've looked at Steve's wording, and it needs *a lot* of work. Most of your
complaints about putting aspect_specification before representation item should
be irrelevant -- the wording shouldn't be talking about either. Especially as
just saying "aspect_specification" is not enough for rules that only apply to
*representation aspects*. Steve seems to have completely forgotten about the
many other kinds of aspects.

Since I'm essentially out of time now, I won't be able to fix up most of this in
time for Draft 15 (coming out tomorrow) or the meeting, so we'll have plenty of
time to hash it out.

(And please don't reply to this message, I don't want any more mail to
file...we'll hash it out at the meeting.)

****************************************************************