!standard 13.3(65) 12-01-12 AI05-0269-1/02 !standard 13.11.3(5) !standard 13.11.4(0) !standard A.18.18(0) !standard A.18.21(0) !standard A.18.22(0) !standard A.18.23(0) !standard A.18.24(0) !standard D.16.1(0) !class Amendment 11-11-09 !status Amendment 2012 12-01-12 !status work item 11-11-09 !status received 11-07-20 !priority Low !difficulty Easy !qualifier Error !subject Editorial comments on Draft 14 !summary Handle editorial comments on Draft 14 !proposal (1) Drop Pragma Preelaborate from D.16.1(3/3) (the package depends on Ada.Real_Time, which is not preelaborated. (2) The Implementation Advice for bounded maps and sets ought to include the kind, so the M.3 summary does not look repetitive. (3) We should always use "holder" as an adjective; using "holder container" if no other option exists. There is only one element in a holder, so use "the element" instead of "elements". (4) There is no type named "Root_Subpool_Type", this should be fixed. (5) 13.11.3(5/3) does not tell us where the aspect is allowed. (6) The list of packages for 13.12.1(2.1/3) includes Interfaces.C.Pointers, which is a generic package. But the wording does not strictly apply to it (a generic package is not a package, and a instance of it is not a language-defined package). This should be fixed. (7) "The aspect Storage_Size" in 13.3(65.2/3) is inconsistent with the following rules which use "The Storage_Size aspect". !wording (1) Remove pragma Preelaborate from D.16.1(3/3). (2) Add "hashed" to A.18.21(21/3), "ordered" to A.18.22(18/3), "hashed" to A.18.23(20/3), and "ordered to A.18.24(17/3), in front of "map" or "set". (3) Change "holder" to "holder container" in A.18.18(70,72,74/3). Change "elements" to "the element" in A.18.18(73/3). (4) Replace "Root_Subpool_Type" with "Root_Subpool" in 13.11.4(19/3). (5) Modify 13.11.3(5/3): The language-defined aspect Default_Storage_Pool may be {specified for a generic instance; it defines} [used to define] the default pool for access types within an instance. (6) Modify 13.12.1(2.1/3): There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages {or instances of language-defined generic packages}. (7) Modify 13.3(65.2/3): Storage_Size The [aspect] Storage_Size {aspect} ... !discussion !corrigendum 13.3(65) @ddel [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 13.11.4(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 13.12.1(2/2) @dinsa @xhang<@xterm There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.> @dinss @xhang<@xterm There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages or instances of language-defined generic packages. Such identifiers can arise as follows:> !corrigendum A.18.18(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.21(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.22(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.23(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.24(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum D.16.1(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !ACATS Test None needed. !ASIS No change needed. !appendix From: Alan Burns Sent: Monday, September 19, 2011 4:51 AM We have just held IRTAW - lots of interesting stuff for post Ada2012! But a couple of 'editorial' issues were noted with regard to D.16.1 package System.Multiprocessors.Dispatching_Domain has pragma Preelaborate. But it also withs Ada.Real-Time that does not have this pragma. This seems to be wrong. ... [Rest omitted here, in AI05-0278-1.] **************************************************************** From: Brad Moore Sent: Wednesday, December 28, 2011 10:29 AM [Part of a larger review... - Editor] A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to the preceding paragraph, and the 'Implementation Advice' tag is also redundant, since it falls under the 'Implementation Advice' section. ... If the preceding paragraphs are necessary, then there is a consistency problem, because some of the containers do not have these redundant paragraphs. **************************************************************** From: Randy Brukardt Sent: Friday, December 30, 2011 11:38 PM > A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to > the preceding paragraph, and the 'Implementation Advice' tag is also > redundant, since it falls under the 'Implementation Advice' section. This is the "marker" note for the what becomes the contents of the Implementation Advice annex (which is automatically generated from these notes). We could consider suppressing these globally (so they aren't shown at all), but doing so would change the paragraph numbers of some AARM notes silently, so that would not be a great idea. ... > If the preceding paragraphs are necessary, then there is a consistency > problem, because some of the containers do not have these redundant > paragraphs. Anything that doesn't have these paragraphs won't show up in the Annex (M.3), which would be a fairly serious bug. There should be one after every implementation advice (or some other note stating that we don't want an annex entry, there is a couple of cases of that). I can't find any missing ones on a quicky random check. If you can, please tell me so that I can fix them somehow. **************************************************************** From: Brad Moore Sent: Saturday, December 31, 2011 10:22 AM The inconsistent containers are ; A.18.22 The Generic Package Containers.Bounded_Ordered_Maps A.18.24 The Generic Package Containers.Bounded_Ordered_Sets **************************************************************** From: Randy Brukardt Sent: Saturday, December 31, 2011 5:25 PM Ah, I see that's intentional, because the wording of the Implementation Advice is identical to the hashed versions. It would look insane to repeat that wording twice in a row in the annex. There should have been a comment in the code (rather than just in the source, where there is one), so you could see why it is omitted. Arguably, omitting these is a bad idea because the section reference is missed in the annex. In that case, we need to change the (normative) wording of all four sets of this advice to add "ordered" and "hashed" appropriately. Should we do that? What do you think? **************************************************************** From: Brad Moore Sent: Tuesday, January 3, 2012 12:22 PM Definitely not a high priority issue, but if it's not too much trouble, I think it would be good to make the changes in the name of consistency, otherwise it looks like an omission. **************************************************************** From: Steve Baird Sent: Monday, January 9, 2012 3:43 PM [Part of a larger review... - Editor] Oh dear. I read 13.11.3 and became very confused. It isn't at all clear for which entities the Default_Storage_Pool aspect may be specified. 5/3 says The language-defined aspect Default_Storage_Pool may be used to define the default pool for access types within an instance. Is this a roundabout way of saying that this aspect may be specified for an instance? It reads like non-normative introductory text. More precise wording is definitely needed, especially when we are doing non-intuitive things like allowing it to be specified via an aspect definition clause for an instance, but only via a pragma for a generic. Or something like that. I can't tell. Did we lose a paragraph or something? **************************************************************** From: Randy Brukardt Sent: Friday, January 13, 2012 1:22 AM ... > Is this a roundabout way of saying that this aspect may be > specified for an instance? Yes (I think). The AARM notes explain the intended model, but I agree that the normative wording ought to match. > It reads like non-normative introductory text. > More precise wording is definitely needed, especially when we > are doing non-intuitive things like allowing it to be > specified via an aspect definition clause for an instance, > but only via a pragma for a generic. Or something like that. > I can't tell. > > Did we lose a paragraph or something? No, that's the wording in the original AI. So it is more that the text was never there. I don't think much additional is actually needed, add a second sentence: "The aspect can be specified for a generic instance". Or maybe it is better to just change the first sentence: The language-defined aspect Default_Storage_Pool may be {specified for a generic instance; it defines} [used to define] the default pool for access types within an instance. ****************************************************************