Version 1.4 of ai05s/ai05-0295-1.txt

Unformatted version of ai05s/ai05-0295-1.txt version 1.4
Other versions for file ai05s/ai05-0295-1.txt
!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)
Replace the paragraph:
by:
!corrigendum 9.10(1)
Replace the paragraph:
If two different objects, including nonoverlapping parts of the same object, are 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.
by:
If two different objects, including nonoverlapping parts of the same object, are 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)
Replace the paragraph:
Operational and Representation Items
by:
Operational and Representation Aspects
!corrigendum 13.1(0.1/1)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
A representation item directly specifies an aspect of representation of the entity denoted by the local_name, except in the case of a type-related representation item, whose 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 subtype-specific (Size and Alignment clauses) or type-related (all others). Subtype-specific aspects may differ for different subtypes of the same type.
by:
A representation item directly specifies a representation aspect of the entity denoted by the local_name, except in the case of a type-related representation item, whose 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 subtype-specific (Size and Alignment clauses) or type-related (all others). Subtype-specific aspects may differ for different subtypes of the same type.
!corrigendum 13.1(9.1/1)
Insert after the paragraph:
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.
the new paragraph:
Unless otherwise specified, it is illegal to specify an operational or representation aspect of a generic formal parameter.
!corrigendum 13.1(10)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
A representation or operational item that is not supported by the implementation is illegal, or raises an exception at run time.
by:
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)
Replace the paragraph:
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.
by:
A 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)
Replace the paragraph:
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.
by:
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 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)
Replace the paragraph:
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.
by:
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 aspect_specifications 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 aspect_specification or operational item that specifies the same aspect of the type.
!corrigedum 13.1(18.2/2)
Replace the paragraph:
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.
by:
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 aspect_specifications or representation items that specified them.
!corrigendum 13.1(20)
Replace the paragraph:
An implementation may interpret aspects of representation in an implementation-defined manner. An implementation may place implementation-defined restrictions on representation items. A 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").
by:
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 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)
Replace the paragraph:
The recommended level of support for all representation items is qualified as follows:
by:
The recommended level of support for the specification of all representation aspects is qualified as follows:
!corrigendum 13.1(21.1/2)
Replace the paragraph:
by:
!corrigendum 13.1(22)
Replace the paragraph:
by:
!corrigendum 13.1(24/2)
Replace the paragraph:
by:
!corrigendum 13.1(25/2)
Replace the paragraph:
by:
!corrigendum 13.1(26/2)
Replace the paragraph:
by:
!corrigendum 13.1(27/2)
Replace the paragraph:
by:
!corrigendum 13.1(28/2)
Replace the paragraph:
For purposes of these rules, the determination of whether a representation item applied to a type 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.
by:
For purposes of these rules, the determination of whether specifying a representation aspect value for a type 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)
Insert new clause:
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: 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.)

****************************************************************
Questions? Ask the ACAA Technical Agent