!standard 13.1(0) 12-02-18 AI05-0295-1/02 !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 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 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. 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 to 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 an 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): {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 {nonconfirming} representation {value was specified for}[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".] 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 an } 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: A 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 @fas 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.a): 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): ... representation {value}[item] ... Modify 13.1(22): An implementation need not support representation items {or aspect_specifications for representation aspects} containing nonstatic expressions, except that an implementation should support a representation item {R or aspect_specification for a representation aspect S} for a given entity if each nonstatic expression in {R or S}[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 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 that denotes any component, protected subprogram, or entry is allowed within an @fa, 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, 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, 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 representation value is specified for any of the following 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 an @i of the entity denoted by the @fa, except in the case of a type-related representation item, whose @fa 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 (Size and Alignment clauses) or @i (all others). Subtype-specific aspects may differ for different subtypes of the same type. @dby A representation item @i a @i of the entity denoted by the @fa, except in the case of a type-related representation item, whose @fa 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 (Size and Alignment clauses) or @i (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 Specifying a representation or operational aspect such that the aspect is not supported by the implementation is illegal, or raises an exception at run time. !corrigendum 13.1(13.1/2) @drepl A @fa 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 is illegal if it has one or more progenitors, and a nonconfirming representation value was specified for an ancestor, and this representation aspect 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 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 @fas 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 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. @dby A @fa or representation item that specifies a representation aspect that would have been chosen in the absence of the @fa or representation item is said to be @i. The aspect value specified in this case is said to be a @i representation aspect value. Other values of the aspect are said to be @i, as are the @fas 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 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 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 @dby @xbullet !corrigendum 13.1(22) @drepl @xbullet @dby @xbullets for representation aspects containing nonstatic expressions, except that an implementation should support a representation item @i or @fa for a representation aspect @i for a given entity if each nonstatic expression in @i or @i is a name that statically denotes a constant declared before the entity.> !corrigendum 13.1(24/2) @drepl @xbullet @dby @xbullet !corrigendum 13.1(25/2) @drepl @xbullet @dby @xbullet !corrigendum 13.1(26/2) @drepl @xbullet @dby @xbullet !corrigendum 13.1(27/2) @drepl @xbullet @dby @xbullet !corrigendum 13.1(28/2) @drepl For purposes of these rules, the determination of whether a representation item applied to a type @i 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 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? ( 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.) ****************************************************************