CVS difference for ai05s/ai05-0269-1.txt

--- ai05s/ai05-0269-1.txt	2012/01/05 06:19:33	1.2
+++ ai05s/ai05-0269-1.txt	2012/01/20 03:34:28	1.3
@@ -1,5 +1,14 @@
-!standard  D.16.1(0)                               11-11-09    AI05-0269-1/01
+!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
@@ -16,15 +25,121 @@
 (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):
 
-** TBD.
+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<No_Implementation_Attributes>
+There are no implementation-defined attributes. This restriction applies only
+to the current compilation or environment, not the entire partition.>
+@dinss
+@xhang<@xterm<No_Implementation_Identifiers>
+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.
@@ -46,6 +161,140 @@
 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
+        <cid:part1.08030602.04050506@shaw.ca>
+A.18.24 The Generic Package Containers.Bounded_Ordered_Sets
+        <cid:part2.01030905.05000005@shaw.ca>
+
+****************************************************************
+
+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. 
 
 ****************************************************************