!standard 3.3.1(10) 10-10-25 AI05-0229-1/01 !standard 3.3.1(21) !class Amendment 10-10-25 !status work item 10-10-25 !status received 10-10-25 !priority Medium !difficulty Easy !subject Specifiable aspects !summary (See proposal.) !problem The new aspect clauses (see AI05-0183-1) provide convinient syntax for specifying aspect values. We ought to be able to use that syntax to specify existing aspects as well as new ones. !proposal !wording [Author's note: I've no idea where the following wording belongs.] The following aspects may be used as an aspect_mark: - Each specifiable attribute may be specified by an attribute_definition_clause, as explained in 13.3, or by an aspect_specification, with the same semantics. - A representation pragma that has a single argument that is a local_name may be specified by an aspect_specification, with the entity being the local_name, the aspect_mark being the same as the pragma name. The aspect_definition is expected to be of type Boolean. The expression shall be static with value True. - Additional aspects that are neither attributes nor pragmas are defined throughout this International Standard. AARM Discussion: The following representation pragmas may also be specified using an aspect_specification: Asynchronous E.4.1(8) Atomic C.6(14) Atomic_Components C.6(14) Controlled 13.11.3(5) Discard_Names C.5(6) Independent C.6(14) Independent_Components C.6(14) Pack 13.2(5) Volatile C.6(14) Volatile_Components C.6(14) Unchecked_Union The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28) End AARM Discussion. (Seems like the above should be part of AI05-0183-1. I can understand why you might want the stuff below in a separate AI.) Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3). Remove all wording for representation pragmas that says this pragma specifies so-and-so aspect: 13.2(5): 5 [A pragma Pack specifies the packing aspect of representation; ] {If Pack is specified, } the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and a pragma Pack causes packing only of the extension part. 13.11.3(5): 5 A pragma Controlled is a representation pragma[ that specifies the controlled aspect of representation]. B.3.3(4/2): 4/2 Unchecked_Union is a representation pragma[, specifying the unchecked union aspect of representation]. C.5(6): No changes needed for Discard_Names. C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] Add Unchecked_Union to the index under "representation pragma". !discussion !ACATS test ACATS tests would be needed for this aspect. !appendix From: Bob Duff Sent: Monday, October 25, 2010 2:44 PM From the Valencia minutes: New Action Items ... Bob Duff ... AI to add wording to explain which non-attribute aspects can be specified via aspect clauses, and the exact semantics for such specification. (See discussion of AI05-0183-1.) Participate in the amendment subcommittee ... ---------------- Tucker would like to make a separate AI to handle changes to individual aspects. But add a general statement about specifiable attributes in this AI. Wording needs to be added to 13.1(9-9.1) to include aspect clauses (to prevent specifying one aspect in multiple ways). Tucker says that he tried to use some common wording in AI-139-2, 4.1.6. This would then be used to create an annex similar to the attribute one. We are electing Bob to do this new AI, using the AI05-0139-2 wording as a model. He will need to A,"fixA," the wording from AI05-0145-2 into this format. [Editor's note: I did this for the wording proposed for AI05-0146-1 and in these minutes for AI05-0153-1]. Randy explained the above privately: > We want the AI which defines which aspects can be specified with the > AI-183 to be separate from AI-183, because it is likely to be large > and it would obscure the more complex wording. OK. I've included some wording below. I think I may be misunderstanding what you want, because it's not all that large. If you have in mind rewriting all the rules for every sort of attribute_definition_clause, then, well... That's NUTS! If this job entails rewriting all of chap 13 (again!) plus a bunch of other stuff, then I think we should back off. It is REALLY not important to allow "Foo with Bar => Baz" when there's already a way to say it. > AI-139-2 defines a couple of aspects in a format that Tucker is > proposing be used for *all* specifiable aspects. You can use that as a > model (or AI-146 or AI-153-1 as I already modified them to use that same format). OK, and as clarified by Tucker privately, some aspects are also attributes, some are also pragmas, and some are just aspects. > We expect that all specifable attributes will be usable as aspects in > aspect clauses in the same way as they can be used in attribute > clauses (that will reduce the needed wording). But we also need > wording for every pragma that can be used as an aspect: probably Pack, > the ones in C.6, Priority, CPU (which is new),... If CPU is new, we could get rid of the pragma, and just make it an aspect. The whole point of aspect_specifications (25 years too late) is to reduce the proliferation of pragmas, each with its own distinct rules. >... etc. Robert had suggested that Pack => False turn off packing (not >sure if that introduces new problems, it definitely would for Atomic). >You'll need to decide if that makes sense. I'm not sure I like the idea of Pack => False. It seems like a neat feature in isolation, but if it requires hard thinking about Atomic and friends, I'm not sure it's worth the trouble. ---------------- I've no idea where the following wording belongs. I'm still not sure exactly what's wanted, so I'm sending this trial baloon to see if it floats. The following aspects may be used as an aspect_mark: - Each specifiable attribute may be specified by an attribute_definition_clause, as explained in 13.3, or by an aspect_specification, with the same semantics. - A representation pragma that has a single argument that is a local_name may be specified by an aspect_specification, with the entity being the local_name, the aspect_mark being the same as the pragma name. The aspect_definition is expected to be of type Boolean. The expression shall be static with value True. - Additional aspects that are neither attributes nor pragmas are defined throughout this International Standard. AARM Discussion: The following representation pragmas may also be specified using an aspect_specification: Asynchronous E.4.1(8) Atomic C.6(14) Atomic_Components C.6(14) Controlled 13.11.3(5) Discard_Names C.5(6) Independent C.6(14) Independent_Components C.6(14) Pack 13.2(5) Volatile C.6(14) Volatile_Components C.6(14) Unchecked_Union The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28) End AARM Discussion. (Seems like the above should be part of AI05-0183-1. I can understand why you might want the stuff below in a separate AI.) Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3). Remove all wording for representation pragmas that says this pragma specifies so-and-so aspect: 13.2(5): 5 [A pragma Pack specifies the packing aspect of representation; ] {If Pack is specified, } the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and a pragma Pack causes packing only of the extension part. 13.11.3(5): 5 A pragma Controlled is a representation pragma[ that specifies the controlled aspect of representation]. B.3.3(4/2): 4/2 Unchecked_Union is a representation pragma[, specifying the unchecked union aspect of representation]. C.5(6): No changes needed for Discard_Names. C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] Add Unchecked_Union to the index under "representation pragma". **************************************************************** From: Tucker Taft Sent: Monday, October 25, 2010 3:10 PM I am interpreting the "[]" as deletions, rather than indicating as redundant. Also, I notice you eliminated the mention that the asynchronous aspect was "type-related." I think we want to preserve the distinction between type-related and subtype-specific aspects. That may affect the legality of specifying the aspect on a subtype declaration. So we should be careful about deleting phrases that include "type-related" or "subtype-specific" unless they show up elsewhere. **************************************************************** From: Bob Duff Sent: Monday, October 25, 2010 5:51 PM > I am interpreting the "[]" as deletions, rather than indicating as > redundant. Right. I get mixed up between {} and []. I think the convention for AI's is {} for insertions, [] for deletions, and Redundant[] for redundancies. The convention in the AARM is [] for redundancies. The convention in the RM is to have no such noise. Please correct me if I'm wrong. >...Also, I notice you eliminated > the mention that the asynchronous aspect was "type-related." So I guess it should be: E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] The Asynchronous aspect is type-related when applied to a type. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:15 PM > Right. I get mixed up between {} and []. I think the convention for > AI's is {} for insertions, [] for deletions, and Redundant[] for > redundancies. The convention in the AARM is [] for redundancies. The > convention in the RM is to have no such noise. > > Please correct me if I'm wrong. That is exactly right. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:42 PM ... > I've no idea where the following wording belongs. I'm still not sure > exactly what's wanted, so I'm sending this trial baloon to see if it > floats. I think it is pretty close. We also need text to introduce the "aspect annex" (the intent is that we will have an annex similar to the attribute one that shows all of the possible aspects). The actual annex will be automatically created somehow. CPU and Priority don't have local names, but they ought to be specifable as aspects. (At least, we ought to consider that!) I'm not sure that Unchecked_Union makes sense here (it's closer to pragma Convention than to the others on this list). I suspect it would be best with the pragmas to simply list the ones that are included (then we don't need to come up with a blanket rule that isn't really quite what we want). ****************************************************************