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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0248-1.txt

--- ai05s/ai05-0248-1.txt	2011/04/02 07:30:36	1.1
+++ ai05s/ai05-0248-1.txt	2011/04/07 06:29:32	1.2
@@ -1,4 +1,36 @@
-!standard x.xx(xx/x)                              11-03-31    AI05-0248-1/01
+!standard A.1(35)                                  11-04-06    AI05-0248-1/02
+!standard A.16(20)
+!standard A.16(82/2)
+!standard A.16.1(0)
+!standard A.17(8/2)
+!standard A.17(22/2)
+!standard A.18.2(147/2)
+!standard A.18.2(149/2)
+!standard A.18.2(239/2)
+!standard A.18.3(88/2)
+!standard A.18.3(152/2)
+!standard A.18.4(43/2)
+!standard A.18.4(75/2)
+!standard A.18.5(53/2)
+!standard A.18.7(38/2)
+!standard A.18.7(96/2)
+!standard A.18.8(75/2)
+!standard A.18.10(0)
+!standard A.18.18(0)
+!standard A.18.19(0)
+!standard A.18.20(0)
+!standard A.18.21(0)
+!standard A.18.22(0)
+!standard A.18.23(0)
+!standard A.18.24(0)
+!standard A.18.25(0)
+!standard A.18.26(9/2)
+!standard A.18.26(11/2)
+!standard A.18.30(0)
+!standard A.19(0)
+!standard B.3(62)
+!standard D.1(29)
+!standard F.3.2(73)
 !class presentation 11-03-31
 !status Amendment 2012 11-03-31
 !status work item 11-03-31
@@ -17,21 +49,466 @@
 Should we improve it? (Yes.)
 
 !recommendation
-
 (See Summary.)
 
 !wording
 
+[Note: /3 paragraph numbers are from draft 11.]
+
+Replace the line containing soft_hyphen in A.1(35) with two lines:
+
+'¨', '©', 'ª', '«',              --168 (16#A8#) .. 171 (16#AB#)
+'¬', soft_hyphen, '®', '¯',        --172 (16#AC#) .. 175 (16#AF#)
+
+Reformat A.16(20.1/3) to:
+
+type Name_Case_Kind is
+   (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);
+
+Modify A.16(82.2/3):
+
+Returns the file name equivalence rule for the directory containing
+Name. Raises Name_Error if Name is not a full name. Returns Case_Sensitive if
+file names that differ only in the case of letters are considered different
+names. If file names that differ only in the case of letters are considered the
+same name, then Case_Preserving is returned if {names have}[the name has] the
+case of the file name used when a file is created; and Case_Insensitive
+{is returned }otherwise. Returns Unknown if the file name equivalence is
+not known.
+
+Modify A.16(30/3):
+
+Returns the leftmost directory part in Name. That is{, it returns} a
+root directory name...
+
+Replace A.17(8/2) and A.17(22/2) by:
+
+procedure Iterate
+   (Process : not null access procedure (Name, Value : in String));
+
+[Note: This is just moving the first '(' to the second line and fixing indentation.]
+
+In A.18.2(147.2/3), A.18.5(53.2/3), and A.18.8(75.2/3),
+replace "Reserve_Capacity is called with the length of Source as the capacity" with
+"Reserve_Capacity (Target, Length (Source)) is called".
+
+In A.18.2(149/2), A.18.3(88/2), A.18.4(43/2), A.18.7(38/2), A.18.10(115/3),
+and A.18.18(52/3), change "...then Move has no effect." to
+"...then the operation has no effect."
+to match the wording of Assign (which is only a few paragraphs above).
+
+Modify A.18.2(239.1/3), A.18.3(152.1/3), A.18.4(75.1/3), A.18.7(96.1/3), and
+A.18.10(), and A.18.18(53/3) as follows: "...with elements of any <<container>>
+parameter [to] {of} the operation."
+
+In A.18.10(66/3), A.18.10(90/3), and A.18.10(115/3) change Count to Node_Count.
+
+Replace A.18.10(70/3) by:
+"Tree'Write writes Node_Count (Tree) - 1 elements to the stream. Tree'Read reads
+Node_Count (Tree) - 1 elements from the stream."
+
+Modify A.18.10(74/3): "...Splice_Subtree or Splice_Children procedures {with T as a parameter}; or"
+
+Modify A.18.10(82/3): ""... Left_Position is different [than] {from} the ..."
+and "... If the result {of the element comparison} is False, the function returns
+False. ..."
+
+In A.18.10(88/3), A.18.10(153/3), A.18.10(156/3), A.18.10(165/3), A.18.25(12/3), and A.18.25(13/3),
+change Subtree_Count to Subtree_Node_Count.
+
+Add a comma after "otherwise" in A.18.10(92/3) and A.18.10(117/3).
+
+Modify A.18.10(94/3): "... designates the root node of [the] {some} tree; ..."
+
+Modify A.18.10(131/3): "... if the cursor designates [the] {a} root node ..."
+
+Modify A.18.10(141/3), A.18.10(143/3), A.18.10(153/3), A.18.10(155/3), A.18.10(156/3),
+and A.18.10(158/3): "If Parent already has child nodes{,} then ..."
+
+Modify A.18.10(155/3): "..."...; {otherwise,}[else] the subtree rooted by ..."
+
+Modify A.18.10(164/3), A.18.10(165/3), and A.18.10(167/3): "If Target_Parent already has
+child elements{,} then ..."
+
+Modify A.18.10(165/3): "..., and {the} overall count of Source is decremented ..."
+
+Move paragraph A.18.30(17/3) after A.18.30(14/3).
+
+Modify A.19(1/3): "... internationalization{-}related characteristics."
+
+Modify A.19(11/3) and A.19(12/3): ""... from the environment{,} then ..."
+
+Change the mode of Update_Element for the Indefinite_Holder
+container (A.18.18(15/3) and A.18.18(45/3)) to "in out".
+
+Delete "(note that distinct elaborations of a type declaration result in distinct types)"
+from A.18.19(12/3), A.18.20(16/3), A.18.21(17/3), A.18.22(14/3), A.18.23(17/3),
+A.18.24(14/3), and A.18.25(16/3).
 
+Add "; Before should return True if Left is to be sorted before Right." to A.18.26(9/2).
+[Editor's note: A similar change was applied directly to AI05-0159-1.]
+
+Add after A.18.26(11/2):
+
+The worst-case time complexity of a call on an instance of Containers.Generic_Sort
+should be O(N**2) or better, and the average time complexity should be better than
+O(N**2), where N is the difference between the Last and First parameters plus 1.
+
+Containers.Generic_Sort should minimize calls to the generic formal Swap.
+
+B.3(62.2/3): "which" --> "that"
+
+D.1(29): "non-standard" should be "nonstandard" (this is the term in the index).
+
+Modify AARM E.2.2(20.b/2) and AARM E.2.3(20.b/2) "...The wording was changed from
+"user-specified" to "available” {Read and Write} attributes..."
+
+Modify AARM E.3(1.a) "The rules guarantee that remote call interface and
+shared passive [packages]{library units} ..."
+
+Add "Result:" to F.3.2(73)
+
+Modify AARM J.2(5.e): "...is not legal in Ada {(and never was legal)}[83, nor
+will it be in Ada 95]. One has to write:
+
 !discussion
 
 These wording changes seem to be an improvement in readability and
-understandability, but are not intended to change the meaning of the words.
+understandability, but are not intended to change the meaning of the words,
+except in the case of clear mistakes. The latter are listed below:
+
+A.18.18(15/3), A.18.18(45/3): The mode of any operation that modifies
+a container should be "in out".
+
+A.18.26(11/2): Generic_Sort should have performance requirements like all of the
+other sorting subprograms in A.18.
+
+!corrigendum A.1(35/2)
+
+@dprepl
+@xcode<   '@unicode<168>', '@unicode<169>', '@unicode<170>', '@unicode<171>', '@unicode<172>', '@unicode<173>', '@unicode<174>', '@unicode<175>',   --@ft<@i<168 (16#A8#) .. 175 (16#AF#)>>>
+@dby
+@xcode<   '@unicode<168>', '@unicode<169>', '@unicode<170>', '@unicode<171>', --@ft<@i<168 (16#A8#) .. 171 (16#AB#)>>
+'@unicode<172>', @ft<@i<soft_hyphen>>, '@unicode<174>', '@unicode<175>', --@ft<@i<172 (16#AC#) .. 175 (16#AF#)>>>
+
+!corrigendum A.16(20/2)
+
+@dinsa
+@xcode<@b<function> Compose (Containing_Directory : @b<in> String := "";
+                  Name                 : @b<in> String;
+                  Extension            : @b<in> String := "") @b<return> String;>
+@dinss
+@xcode<@b<type> Name_Case_Kind @b<is>
+   (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);>
+
+@xcode<@b<function> Name_Case_Equivalence (Name : @b<in> String) @b<return> Name_Case_Kind;>
+
+!corrigendum A.16(82/2)
+
+@dinsa
+@xindent<Returns the name of the external file with the specified
+Containing_Directory, Name, and Extension. If Extension is the null string, then
+Name is interpreted as a simple name; otherwise Name is interpreted as a base
+name. The exception Name_Error is propagated if the string given as
+Containing_Directory is not null and does not allow the identification of a
+directory, or if the string given as Extension is not null and is not a possible
+extension, or if the string given as Name is not a possible simple name (if
+Extension is null) or base name (if Extension is non-null).>
+@dinss
+@xcode<@b<function> Name_Case_Equivalence (Name : @b<in> String) @b<return> Name_Case_Kind;>
+
+@xindent<Returns the file name equivalence rule for the directory containing
+Name. Raises Name_Error if Name is not a full name. Returns Case_Sensitive if
+file names that differ only in the case of letters are considered different
+names. If file names that differ only in the case of letters are considered the
+same name, then Case_Preserving is returned if names have the case of the file
+name used when a file is created; and Case_Insensitive is returned otherwise. Returns
+Unknown if the file name equivalence is not known.>
+
+!corrigendum A.16.1(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.17(8/2)
+
+@drepl
+@xcode<   @b<procedure> Iterate (
+       Process : @b<not null access procedure> (Name, Value : @b<in> String));>
+@dby
+@xcode<   @b<procedure> Iterate
+      (Process : @b<not null access procedure> (Name, Value : @b<in> String));>
+
+!corrigendum A.17(22/2)
+
+@drepl
+@xcode<@b<procedure> Iterate (
+     Process : @b<not null access procedure> (Name, Value : @b<in> String));>
+@dby
+@xcode<@b<procedure> Iterate
+   (Process : @b<not null access procedure> (Name, Value : @b<in> String));>
+
+!corrigendum A.18.2(147/2)
+
+@dinsa
+@xindent<The element designated by Position is not an empty element after successful
+completion of this operation.>
+@dinss
+@xcode<@b<procedure> Assign (Target : @b<in out> Vector; Source : @b<in> Vector);>
+
+@xindent<If Target denotes the same object as Source, the operation has no
+effect. If the length of Source is greater than the capacity of Target,
+Reserve_Capacity (Target, Length (Source)).
+Each element of Source is assigned to the corresponding element of Target.>
+
+!corrigendum A.18.2(149/2)
+
+@drepl
+If Target denotes the same object as Source, then Move operation has no
+effect.  Otherwise, Move first calls Reserve_Capacity (Target, Length (Source))
+and then Clear (Target); then, each element from Source
+is removed from Source and inserted into Target in the original
+order. The length of Source is 0 after a successful call to Move.
+@dby
+If Target denotes the same object as Source, then the operation has no
+effect.  Otherwise, Move first calls Reserve_Capacity (Target, Length (Source))
+and then Clear (Target); then, each element from Source
+is removed from Source and inserted into Target in the original
+order. The length of Source is 0 after a successful call to Move.
+
+!corrigendum A.18.2(239/2)
+
+@dinsa
+Calling Merge in an instance of Generic_Sorting with either Source
+or Target not ordered smallest first using the provided generic formal
+"<" operator is a bounded error. Either Program_Error is raised after
+Target is updated as described for Merge, or the operation works as defined.
+@dinst
+It is a bounded error for the actual function associated with
+a generic formal subprogram, when called as part of an operation
+of this package, to tamper with elements of any Vector parameter
+of the operation. Either Program_Error is raised, or the operation
+works as defined on the value of the Vector either prior to, or
+subsequent to, some or all of the modifications to the Vector.
+
+!corrigendum A.18.3(88/2)
+
+@drepl
+@xindent<If Target denotes the same object as Source, then Move has no effect.
+Otherwise, equivalent to Assign (Target, Source) followed by Clear (Source).>
+@dby
+@xindent<If Target denotes the same object as Source, then the operation has no effect.
+Otherwise, equivalent to Assign (Target, Source) followed by Clear (Source).>
+
+!corrigendum A.18.3(152/2)
+
+@dinsa
+Calling Merge in an instance of Generic_Sorting with either Source
+or Target not ordered smallest first using the provided generic formal
+"<" operator is a bounded error. Either Program_Error is raised after
+Target is updated as described for Merge, or the operation works as defined.
+@dinst
+It is a bounded error for the actual function associated with
+a generic formal subprogram, when called as part of an operation
+of this package, to tamper with elements of any List parameter
+of the operation. Either Program_Error is raised, or the operation
+works as defined on the value of the List either prior to, or
+subsequent to, some or all of the modifications to the List.
+
+!corrigendum A.18.4(43/2)
+
+@drepl
+@xindent<If Target denotes the same object as Source, then Move has no effect. Otherwise,
+equivalent to Assign (Target, Source) followed by Clear (Source).>
+@dby
+@xindent<If Target denotes the same object as Source, then the operation has no effect. Otherwise,
+equivalent to Assign (Target, Source) followed by Clear (Source).>
+
+!corrigendum A.18.4(75/2)
+
+@dinsa
+@xindent<Iterate calls Process.@b<all> with a cursor that designates each node
+in Container, starting with the first node and moving the cursor according
+to the successor relation. Program_Error is propagated if Process.@b<all>
+tampers with the cursors of Container. Any exception raised by Process.@b<all>
+is propagated.>
+@dinss
+@s8<@i<Bounded Error>>@hr
+
+It is a bounded error for the actual function associated with
+a generic formal subprogram, when called as part of an operation
+of a map package, to tamper with elements of any map parameter
+of the operation. Either Program_Error is raised, or the operation
+works as defined on the value of the map either prior to, or
+subsequent to, some or all of the modifications to the map.
+
+!corrigendum A.18.5(53/2)
+
+@dinsa
+In addition to the semantics described in A.18.4, Clear does not affect the capacity
+of Container.
+@dinst
+@xcode<@b<procedure> Assign (Target : @b<in out> Map; Source : @b<in> Map);>
+
+@xindent<In addition to the semantics described in A.18.4, if the length of Source is
+greater than the capacity of Target, Reserve_Capacity (Target, Length (Source)) is called
+before assigning any elements.>
+
+!corrigendum A.18.7(38/2)
+
+@drepl
+@xindent<If Target denotes the same object as Source, then Move has no effect.
+Otherwise, equivalent to Assign (Target, Source) followed by Clear (Source).>
+@dby
+@xindent<If Target denotes the same object as Source, then the operation has no effect.
+Otherwise, equivalent to Assign (Target, Source) followed by Clear (Source).>
+
+!corrigendum A.18.7(96/2)
+
+@dinsa
+If Element_Type is unconstrained and definite, then the actual Element
+parameter of Process.@b<all> shall be unconstrained.
+@dinss
+@s8<@i<Bounded Error>>@hr
+
+It is a bounded error for the actual function associated with
+a generic formal subprogram, when called as part of an operation
+of a set package, to tamper with elements of any set parameter
+of the operation. Either Program_Error is raised, or the operation
+works as defined on the value of the set either prior to, or
+subsequent to, some or all of the modifications to the set.
+
+!corrigendum A.18.8(75/2)
+
+@dinsa
+In addition to the semantics described in A.18.7, Clear does not affect the capacity
+of Container.
+@dinst
+@xcode<@b<procedure> Assign (Target : @b<in out> Set; Source : @b<in> Set);>
+
+@xindent<In addition to the semantics described in A.18.7, if the length of Source is
+greater than the capacity of Target, Reserve_Capacity (Target, Length (Source)) is called
+before assigning any elements.>
+
+!corrigendum A.18.10(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.18(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.19(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.20(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.21(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.22(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.23(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.24(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.25(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.18.26(9/2)
+
+@drepl
+Force a conflict; real text found in the conflict file.
+@dby
+Still a conflict.
+
+!corrigendum A.18.26(11/2)
+
+@dinsa
+Containers.Generic_Array_Sort and Containers.Generic_Constrained_Array_Sort
+should minimize copying of elements.
+@dinst
+The worst-case time complexity of a call on an instance of Containers.Generic_Sort
+should be O(@i<N>**2) or better, and the average time complexity should be better
+than O(@i<N>**2), where @i<N> is is the difference between the Last and First
+parameters plus 1.
+
+Containers.Generic_Sort should minimize calls to generic formal Swap.
+
+!corrigendum A.18.30(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum A.19(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
+!corrigendum B.3(62)
 
-!corrigendum xx.xx(xx/x)
+@drepl
+Force a conflict; real text found in the conflict file.
+@dby
+Still a conflict.
 
+!corrigendum D.1(29)
 
+@drepl
+@xindent<@s9<6  An implementation may provide a non-standard mode in which
+tasks inherit priorities under conditions other than those specified above.>>
+@dby
+@xindent<@s9<6  An implementation may provide a nonstandard mode in which
+tasks inherit priorities under conditions other than those specified above.>>
 
+!corrigendum F.03.02(74)
+
+@drepl
+@xcode<123456.78     Picture:  "-$$$**_***_**9.99"
+                        "bbb$***123,456.78"
+                        "bbFF***123.456,78" (currency = "FF",
+                                             separator = '.',
+                                             radix mark = ',')>
+@dby
+@xcode<123456.78     Picture:  "-$$$**_***_**9.99"
+              Result:   "bbb$***123,456.78"
+                        "bbFF***123.456,78" (currency = "FF",
+                                             separator = '.',
+                                             radix mark = ',')>
+
+
 !ACATS test
 
 No additional tests should be needed; the original AIs outline any needed
@@ -409,10 +886,10 @@
 Did you print it out, or read it online?
 How long did it take?
 
-> I used "original" this way in a number of AARM notes. Since they are 
-> AARM notes, I can just change them - won't take long. But I'd like an 
+> I used "original" this way in a number of AARM notes. Since they are
+> AARM notes, I can just change them - won't take long. But I'd like an
 > alternative wording. "Initial Ada 2005"? "Uncorrected Ada 2005"? "Unmodified Ada 2005"?
-> "2007 version of the Ada 2005"? ;-) "Ada 2005 as defined by directly 
+> "2007 version of the Ada 2005"? ;-) "Ada 2005 as defined by directly
 > by Amendment 1"?
 
 "original Ada 2005" expresses perfectly what you mean.
@@ -435,7 +912,7 @@
 
 I read the bits I was told to read. I read it online.
 
-How long?  Too long!!   I cannot remember. Most time was taken over puzzling 
+How long?  Too long!!   I cannot remember. Most time was taken over puzzling
 cases where more than one AI affected a paragraph.
 
 ****************************************************************
@@ -443,31 +920,1318 @@
 From: Randy Brukardt
 Sent: Friday, April  1, 2011  11:19 PM
 
-> > >3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005} 
+> > >3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005}
 > > >          The following word
-> > >          is not reserved in Ada 2005, but [are]{is} 
+> > >          is not reserved in Ada 2005, but [are]{is}
 > > >          reserved in Ada 2012: some. Use{s}
-> > >          of this word as an identifier will need to be 
+> > >          of this word as an identifier will need to be
 > > >          changed, but we do not expect them to be common.
-> 
+>
 > There are some some in the AdaCore test suite.
 
 The above is essentially the boilerplate used to justify new reserved words.
 I don't actually believe it.
 
-Besides the somes in the AdaCore test suite, there are a lot of somes in the source
-to the Janus/Ada compiler. These were the reasons that we tried to use an unreserved
-keyword. As usual, the US was in favor, the rest of the world wasn't.
+Besides the somes in the AdaCore test suite, there are a lot of somes in the
+source to the Janus/Ada compiler. These were the reasons that we tried to use an
+unreserved keyword. As usual, the US was in favor, the rest of the world wasn't.
 
 I suspect this will bite a lot of code, but I can hardly write the truth here:
 
-...Use{s} of this word as an identifier will need to be changed; there probably will
-be a lot of them in some code (there is in mine!). We tried to avoid this incompatibility,
-but the idea of unreserved keywords makes our European reviewers uncomfortable and they have
-the majority of votes at WG 9, so we had to live with this incompatibility. If this bothers
-you, please complain to the members of your national body (especially if you are European);
-maybe we'll have enough votes next time.
+...Use{s} of this word as an identifier will need to be changed; there probably
+will be a lot of them in some code (there is in mine!). We tried to avoid this
+incompatibility, but the idea of unreserved keywords makes our European
+reviewers uncomfortable and they have the majority of votes at WG 9, so we had
+to live with this incompatibility. If this bothers you, please complain to the
+members of your national body (especially if you are European); maybe we'll have
+enough votes next time.
 
 :-) :-)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, October 14, 2010  3:52 PM
+
+Most of the rivets on this boilerplate are perfectly in place.  Three nits:
+
+A.1. (35/3)  The line containing soft_hyphen in the declaration for type Character
+will have to be split
+
+A.3.5 (28-50) : the end of each description for the classification functions is
+inconsistent: sometimes ", otherwise return False.", at other times ". Otherwise
+returns False."  In functions in Character.Conversion, only the True condition is given,
+so maybe the "otherwise" can be omitted.
+
+A.4.11 (47/3) : end of sentence:  "Wide_String of 16-bit containing.."  insert
+"values" after "bit".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April  6, 2011  10:33 PM
+
+> Most of the rivets on this boilerplate are perfectly in
+> place.  Three nits:
+>
+> A.1. (35/3)  The line containing soft_hyphen in the
+> declaration for type Character will have to be split
+
+Yes, I've added that to the AI.
+
+> A.3.5 (28-50) : the end of each description for the
+> classification functions is inconsistent: sometimes ",
+> otherwise return False.", at other times ". Otherwise returns
+> False."  In functions in Character.Conversion, only the True
+> condition is given, so maybe the "otherwise" can be omitted.
+
+This appears to have been addressed in the AI's editorial review. There
+is still a minor difference: some of the longer ones are "; otherwise" rather
+than ", otherwise", as there are already commas in the preceding text. I think
+that's acceptable (and I don't want to mess around changing dozens of commas to
+semicolons).
+
+The old routines in Character.Conversions are wrong about this, they should
+include ", otherwise returns False" as well. But we are not changing old text
+unless we have some reason to change it otherwise. (Well, AdaCore *could* up my
+grant by $5K, then I'd be happy to do it. :-)
+
+> A.4.11 (47/3) : end of sentence:  "Wide_String of 16-bit
+> containing.."  insert  "values" after "bit".
+
+The original AI is correct on this, so looks like a mistake I somehow made in the
+draft Standard. I'll just patch it up there.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Saturday, October 16, 2010  1:00 AM
+
+Here are my review comments on sections 16-17, 18.7-18.10, and 19.
+
+Have a good weekend. :-)
+
+Section 16 (Directories)
+----------
+
+16(20.1/3): It would be nice to have better formatting for the enumeration type,
+rather than having one literal pushed to the next line.  Perhaps the literals
+could be put on a separate line or given in a column:
+
+type Name_Case_Kind is
+       (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);
+
+or
+
+type Name_Case_Kind is (Unknown,
+                        Case_Sensitive,
+                        Case_Insensitive,
+                        Case_Preserving);
+
+
+16(82.2/3): The fourth sentence ("If file names that differ only...") seems a
+little awkward wrt to wording about what's returned.  Specifically, I think that
+the "otherwise" part should say something like "and Case_Insensitive {is
+returned} otherwise").
+
+Also, in that same sentence, in the phrase "then Case_Preserving is returned if
+the name has the case of the file name used when a file is created", it's not
+clear to me what the referent of "the name" is.  Presumably it's not referring
+to the parameter Name.  I guess it's referring to some arbitrary name, but it
+reads confusingly to me, though I think I understand what's intended.  Not sure
+what to suggest for better wording though.
+
+
+Section 16.1 (Directories.Hierarchical_File_Names)
+------------
+
+16.1(16/3): Change "useable" to "usable" (the more common spelling).
+
+16.1(30/3): In the first sentence, "in" is improperly written in boldface.
+Also, I suggest this change to the beginning of the second sentence:
+
+  "That is{, it returns} a root directory name...".
+
+
+Section 17 (Environment_Variables)
+----------
+
+Note: This section was assigned to me, though it hasn't changed as far as I can
+tell.  While looking at it, I happened to notice the following minor formatting
+nit:
+
+17(8/2): Formatting: If the spec of Iterate won't fit on one line, it would at
+least be nicer to move the "(" down to the next line. To me it looks ugly
+hanging at the end of a line by itself.
+
+
+Section 18 (Containers)
+----------
+
+This wasn't assigned to me, but I noticed an AARM typo:
+
+In the AARM, 18(4.j/3) has a typo: "predicable" should be "predictable".
+
+
+Section 18.7 (Sets)
+------------
+
+18.7(36.2/3): The wording of the Assign semantics for Sets is the same as for
+other container Assign routines, but for Sets it doesn't sound right.  What does
+"each element of Source is assigned to the corresponding element of Target" mean
+in the case of a set?  The Target set might not have any "corresponding"
+elements.  Also, if there's an element that is in the Target but not in the
+Source, it sounds like that element would remain as is, but that surely is not
+intended (one interpretation would be that the assign is like a union operator,
+but that can't be right).
+
+Perhaps it could say something like "Assign first clears Target, and then for
+each element of Source, an equivalent element is inserted in Target."
+
+18.7(96.1/3): Replace "to" with "of" in the phrase "tamper with elements of any
+Set parameter [to] {of} the operation".
+
+
+Section 18.8 (Containers.Hashed_Sets)
+------------
+
+18.8(75.1/3): In the semantics of Assign, it says "Reserve_Capacity is called
+with the length of source...", but it doesn't say what set is passed to
+Reserve_Capacity.  Obviously it should be Target, but that should be stated.
+
+18.8(88.e/3): Remove extra 'that' ('...that that...')
+
+The "Wording Changes from Ada 2005" section doesn't cover the changes due to
+AI05-0001 (or is that OK because the "Incompatibilities with Ada 2005" section
+covers it?).
+
+
+Section 18.9 (Containers.Ordered_Sets)
+------------
+
+In the vicinity of 18.9(81.1/3) (spec for Copy), the semantic specification of
+the new procedure Assign is missing.
+
+18.8(116.e/3): Remove extra 'that' ('...that that...')
+
+The "Wording Changes from Ada 2005" section doesn't cover the changes due to
+AI05-0001 (or is that OK because the "Incompatibilities with Ada 2005" section
+covers it?).
+
+
+Section 18.10 (Containers.Multiway_Trees)
+-------------
+
+18.10(66/3): "Count (Empty_Tree)" should be "Node_Count (Empty_Tree)".
+
+18.10(70/3): "Tree.Count-1" should be "Tree.Node_Count-1" (two places).
+Also, I notice that the usual style is to use normal function call notation,
+rather than prefix-call form (as in para. 66/3), so maybe this should be written
+as "Node_Count (Tree) - 1"?
+
+General editorial: There are a bunch of places in this section where calls are
+written as Count rather than Node_Count, as well as Subtree_Count rather than
+Subtree_Node_Count.  Those should be searched for and fixed.
+  (e.g., paragraphs 90/3, 115/3)
+
+18.10(74/3): "... that is, it calls the Splice_Subtree or Splice_Children
+procedures {with T as a parameter}; ...".  (For consistency with other sentences
+in the bulleted list.)
+
+18.10(82/3): "... Left_Position is different [than] {from} the ..."
+(The phrase "different from" is generally preferred to "different than".)
+
+18.10(82/3): For added clarity I suggest the following addition to this
+sentence: "If the result {of the element comparison} is False, the function
+returns False."
+
+18.10(92/3): Add a comma in "otherwise{,} Depth ...".
+NOTE: In this section, there are several other cases of a leading "otherwise"
+that should be followed by a comma (e.g., pp. 92/3, 104/3, 108/3, 117/3, 119/3,
+167/3, ...).
+
+18.10(94/3): "... designates the root node of [the] {some} tree; ..."
+
+18.10(109/3): This sentence says that "the actual Element parameter of
+Process.all shall be unconstrained".  I would have expected that sort of "shall"
+paragraph to be in an "Implementation Requirements" paragraph, though I see that
+this wording is used for other containers since Ada 2005, so there's precedent.
+Anyway, I note that there's an AARM paragraph, such as the one for Vectors
+(18.2(142.a/2)), that explains it, and I think it would be good to include that
+paragraph here as well.
+
+18.10(131/3): "... if the cursor designates [the] {a} root node ..."
+
+18.10(153/3): Add a comma: "If Parent already has child nodes{,} then ..."
+
+18.10(155/3): In the phrase "...; else the subtree rooted by ...", I suggest
+replacing "else" with "otherwise,", for consistency with wording in other rules.
+(It's also seems odd to start a sentence with "else", even if it does follow a
+';'.  Another choice would be to change the semicolon to a comma.)
+
+18.10(164/3): Add comma: "If Target_Parent already has child elements{,} then.."
+
+18.10(165/3): Add comma: "If Target_Parent already has child elements{,} then.."
+
+18.10(165/3): Add "the": "..., and {the} overall count of Source is decremented"
+
+18.10(167/3): Add comma: "If Target_Parent already has child elements{,} then.."
+
+18.10(195/3): The "in out" in the third sentence should be in boldface.
+
+
+Section 19 (Locales)
+----------
+
+A.19(1/3): Add a hyphen: "... internationalization{-}related characteristics."
+
+A.19(5/3): I wonder if the constant should be named "Language_Undetermined"
+rather than "Language_Unknown", since the code "und" is short for undetermined.
+Otherwise, it looks like a typo (I initially thought that "und" might be a typo
+for "unk", until I googled ISO 639-3:-).
+
+A.19(11/3): Add a comma: "... from the environment{,} then Language returns..."
+
+A.19(12/3): Add a comma: "... from the environment{,} then Country returns..."
+
+
+---(end of Draft 10 comments)---
+
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April  6, 2011  8:43 PM
+
+> Here are my review comments on sections 16-17, 18.7-18.10, and 19.
+...
+> Section 16 (Directories)
+> ----------
+>
+> 16(20.1/3): It would be nice to have better formatting for the
+> enumeration type, rather than having one literal pushed to the next
+> line.  Perhaps the literals could be put on a separate line or given
+> in a column:
+>
+> type Name_Case_Kind is
+>        (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);
+>
+> or
+>
+> type Name_Case_Kind is (Unknown,
+>                         Case_Sensitive,
+>                         Case_Insensitive,
+>                         Case_Preserving);
+
+OK. I used the first, presuming it fits in the printed Standard.
+
+> 16(82.2/3): The fourth sentence ("If file names that differ
+> only...") seems a little awkward wrt to wording about what's returned.
+> Specifically, I think that the "otherwise" part should say something
+> like "and Case_Insensitive {is returned} otherwise").
+
+OK.
+
+> Also, in that same sentence, in the phrase "then
+> Case_Preserving is returned if the name has the case of the
+> file name used when a file is created", it's not clear to me
+> what the referent of "the name" is.  Presumably it's not
+> referring to the parameter Name.  I guess it's referring to
+> some arbitrary name, but it reads confusingly to me, though I
+> think I understand what's intended.  Not sure what to suggest
+> for better wording though.
+
+"the name has" -> "names have" to make it clear that it is talking about
+names in general and not any specific name.
+
+> Section 16.1 (Directories.Hierarchical_File_Names)
+> ------------
+>
+> 16.1(16/3): Change "useable" to "usable" (the more common spelling).
+
+This is just an RM-only typo, not some intentional funny spelling.
+
+> 16.1(30/3): In the first sentence, "in" is improperly written
+> in boldface.
+> Also, I suggest this change to the beginning of the second sentence:
+>
+>   "That is{, it returns} a root directory name...".
+
+OK. The first is a RM-only typo.
+
+> Section 17 (Environment_Variables)
+> ----------
+>
+> Note: This section was assigned to me, though it hasn't
+> changed as far as I can tell.  While looking at it, I
+> happened to notice the following minor formatting nit:
+>
+> 17(8/2): Formatting: If the spec of Iterate won't fit on one
+> line, it would at least be nicer to move the "(" down to the
+> next line.
+> To me it looks ugly hanging at the end of a line by itself.
+
+Also A.17(22/2). Ugh, but you are right that the Standard generally doesn't
+format routines this way. Fixed.
+
+
+> Section 18 (Containers)
+> ----------
+>
+> This wasn't assigned to me, but I noticed an AARM typo:
+>
+> In the AARM, 18(4.j/3) has a typo: "predicable" should be
+> "predictable".
+
+Humm, this gave me a number of ideas what the original word might mean. That
+told me it was time to go home for tonight. ;-)
+
+
+> Section 18.7 (Sets)
+> ------------
+>
+> 18.7(36.2/3): The wording of the Assign semantics for Sets is
+> the same as for other container Assign routines, but for Sets
+> it doesn't sound right.  What does "each element of Source is
+> assigned to the corresponding element of Target" mean in the
+> case of a set?  The Target set might not have any
+> "corresponding" elements.  Also, if there's an element that
+> is in the Target but not in the Source, it sounds like that
+> element would remain as is, but that surely is not intended
+> (one interpretation would be that the assign is like a union
+> operator, but that can't be right).
+>
+> Perhaps it could say something like "Assign first clears
+> Target, and then for each element of Source, an equivalent
+> element is inserted in Target."
+
+This problem has nothing to do with sets; it exists for almost all of the
+containers. What is the "corresponding" element of an empty list or map? It
+doesn't make much sense even for a vector: one might imagine that the
+"corresponding" element is the one with the same index, but those aren't
+accessible unless the length is changed.
+
+Part of the problem is the "Set" as a container name brings with it baggage
+which is not relevant to the containers. If you wanted to truly describe
+these as sets, virtually all of the wording would need to be different than
+the similar map container -- which would emphasize the minor differences
+rather than the strong similarities.
+
+If we're going to change any of them to use some other wording, then I think
+we need to do that to all of them (all six containers use variations of this
+wording). But I don't know how to do that for most of the containers (the
+Tree version has far worse hand-waving than the Set - but you didn't
+complain about that for some reason). But doing so seems to describe an
+operation very different than ":=", while this operation is supposed to be
+identical to ":=" other than for the bounded forms.
+
+So I would rather find a way to describe this similarly to ":="; and what we
+have seems to be the best way to do that.
+
+I'll put this on the open item discussion list because I don't see a clear
+response.
+
+> 18.7(96.1/3): Replace "to" with "of" in the phrase "tamper
+> with elements of any Set parameter [to] {of} the operation".
+
+OK. Note that this wording exists in all of the base containers, so I
+changed it in 6 places.
+
+> Section 18.8 (Containers.Hashed_Sets)
+> ------------
+>
+> 18.8(75.1/3): In the semantics of Assign, it says
+> "Reserve_Capacity is called with the length of source...",
+> but it doesn't say what set is passed to Reserve_Capacity.
+> Obviously it should be Target, but that should be stated.
+
+This also exists in all of the containers that have Reserve_Capacity. Didn't
+anyone review this stuff?? (The answer is clearly no, unfortunately.)
+
+I changed all of these to be much closer to the similar wording in Move:
+
+"Reserve_Capacity (Target, Length (Source)) is called."
+
+> 18.8(88.e/3): Remove extra 'that' ('...that that...')
+
+OK. As a new AARM note, this just gets changed without marking.
+
+> The "Wording Changes from Ada 2005" section doesn't cover the
+> changes due to AI05-0001 (or is that OK because the
+> "Incompatibilities with Ada 2005" section covers it?).
+
+Yes, of course. "Wording Changes" sections are solely to talk about things
+not covered in other "from Ada 2005" sections. And Bob would prefer fewer
+"Wording Changes" sections, not more. If the wording changes are really
+obvious, I'll not put one of these in at all. Their primary purpose is to
+show the difference between "Binding Interpretations" and "Amendments"
+anyway.
+
+> Section 18.9 (Containers.Ordered_Sets)
+> ------------
+>
+> In the vicinity of 18.9(81.1/3) (spec for Copy), the semantic
+> specification of the new procedure Assign is missing.
+
+As with all routines that are not changed from the "base" definition in
+A.18.7, Assign is not mentioned here intentionally. There is nothing to say.
+
+...
+
+> Section 18.10 (Containers.Multiway_Trees)
+> -------------
+>
+> 18.10(66/3): "Count (Empty_Tree)" should be "Node_Count (Empty_Tree)".
+
+Ugh. The fairly last-minute change from Count to Node_Count was not made
+consistently, because it is not possible to reliably search for Count (you
+get hits from text and from Count_Type that should not be changed).
+
+> 18.10(70/3): "Tree.Count-1" should be "Tree.Node_Count-1"
+> (two places).
+> Also, I notice that the usual style is to use normal function
+> call notation, rather than prefix-call form (as in para.
+> 66/3), so maybe this should be written as "Node_Count (Tree) - 1"?
+
+OK. But I note that there are lots of places where we use the prefix-call
+form (not so much in this clause). I'll change this clause, but I'm not
+going to try to scrub the rest of A.18 for such uses.
+
+> General editorial: There are a bunch of places in this
+> section where calls are written as Count rather than
+> Node_Count, as well as Subtree_Count rather than
+> Subtree_Node_Count.  Those should be searched for and fixed.
+>   (e.g., paragraphs 90/3, 115/3)
+
+As noted above, searching for Count is not reliable. I've already done it at
+least twice in the past (when it was changed, and when John reviewed it),
+and obviously that is not working. There are more than 70 occurrences of
+"Count" in this clause and the related ones! I'll fix what you mentioned
+above (I can't find any others followed by "(") and the Subtype_Count cases,
+but I don't see any reason to repeat failed tasks ("Count" proper). Please
+tell me where you see problems in the future -- searching has proven over
+and over to be unreliable. (It also doesn't help much because I still have
+to record the paragraph number of the changes and make them in three or four
+different places - searching and find only one occurrence makes things
+worse, not better.)
+
+> 18.10(74/3): "... that is, it calls the Splice_Subtree or
+> Splice_Children procedures {with T as a parameter}; ...".
+> (For consistency with other sentences in the bulleted list.)
+
+OK.
+
+> 18.10(82/3): "... Left_Position is different [than] {from} the ..."
+> (The phrase "different from" is generally preferred to
+> "different than".)
+
+If you say so.
+
+> 18.10(82/3): For added clarity I suggest the following
+> addition to this
+> sentence: "If the result {of the element comparison} is
+> False, the function returns False."
+
+OK on both.
+
+> 18.10(92/3): Add a comma in "otherwise{,} Depth ...".
+
+OK.
+
+> NOTE: In this section, there are several other cases of a
+> leading "otherwise"
+> that should be followed by a comma (e.g., pp. 92/3, 104/3,
+> 108/3, 117/3, 119/3, 167/3, ...).
+
+Actually, most of these are copies of wording found elsewhere in the
+containers section. (There are five copies of "Otherwise Replace_Element",
+for instance). It's relatively easy to fix the ones in this clause, but the
+others would be a major pain.
+I don't think it makes sense to spend the effort to fix the others, and I
+don't like the idea of making the wording in this clause different than the
+rest of the standard.
+
+What we could do is give you an action item to find all of the commas you
+want fixed (in the *entire* standard), listing them all by paragraph number,
+and then (presuming the rest of the ARG agrees) just fixing them without any
+formal marked change. That's been done in other cases (capitalization of Id
+foremost among them). But I need a list of changes in case anyone asks, and
+I personally am not going to generate that...
+
+I'll put this on the open issue list for future discussion.
+
+> 18.10(94/3): "... designates the root node of [the] {some} tree; ..."
+
+OK.
+
+> 18.10(109/3): This sentence says that "the actual Element
+> parameter of Process.all shall be unconstrained".  I would
+> have expected that sort of "shall" paragraph to be in an
+> "Implementation Requirements" paragraph, though I see that
+> this wording is used for other containers since Ada 2005, so
+> there's precedent.  Anyway, I note that there's an AARM
+> paragraph, such as the one for Vectors (18.2(142.a/2)), that
+> explains it, and I think it would be good to include that
+> paragraph here as well.
+
+OK, as an AARM change it will not appear in an AI.
+
+> 18.10(131/3): "... if the cursor designates [the] {a} root node ..."
+
+OK.
+
+> 18.10(153/3): Add a comma: "If Parent already has child
+> nodes{,} then ..."
+
+OK. There are a number of these scattered about; you noticed some of them,
+but I found some additional ones (some talk about "child elements" instead).
+I presume that they all need to be changed the same way whether or not you
+previously noted them.
+
+> 18.10(155/3): In the phrase "...; else the subtree rooted by
+> ...", I suggest replacing "else" with "otherwise,", for
+> consistency with wording in other rules.
+> (It's also seems odd to start a sentence with "else", even if
+> it does follow a ';'.  Another choice would be to change the
+> semicolon to a comma.)
+
+OK.
+
+...
+> 18.10(165/3): Add "the": "..., and {the} overall count of
+> Source is decremented"
+
+OK.
+
+> 18.10(195/3): The "in out" in the third sentence should be in
+> boldface.
+
+This is correct in the !corrigendum text, so it is just a formatting bug in
+the RM - as such it won't appear in the AI.
+
+> Section 19 (Locales)
+> ----------
+>
+> A.19(1/3): Add a hyphen: "... internationalization{-}related
+> characteristics."
+
+OK.
+
+> A.19(5/3): I wonder if the constant should be named
+> "Language_Undetermined"
+> rather than "Language_Unknown", since the code "und" is short
+> for undetermined.
+> Otherwise, it looks like a typo (I initially thought that
+> "und" might be a typo for "unk", until I googled ISO 639-3:-).
+
+I'm not qualified to answer this one (at the very least, Brad ought to
+comment); I put it on the open issues list for tomorrow's call. I do think
+if we change one, we need to change both "Language_Unknown" and
+"Country_Unknown". Too confusing otherwise.
+
+> A.19(11/3): Add a comma: "... from the environment{,} then
+> Language returns..."
+>
+> A.19(12/3): Add a comma: "... from the environment{,} then
+> Country returns..."
+
+OK for both.
+
+> ---(end of Draft 10 comments)---
+
+Thank goodness; it's taken me parts of three days to deal with these...
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, September 21, 2010  5:07 AM
+
+> Here are the assignments:
+>             Jean-Pierre Rosen       A.5-A.15; A.18.17-A.18.26
+
+Here is my homework:
+
+A.18.17(7/3) made me look at A.18.10(109/3) which says: "if element_type is ...
+definite", which is a bit strange since Element_Type is necessarily definite.
+
+A.18.18(45/3): shouldn't the Container parameter to Update_Element be "in out"?
+although it can be implemented as "in" because of hidden pointers, other
+containers have it as "in out" (and it is logically "in out").
+
+A.18.18(48/3) says "If Target denotes the same object as Source, the operation
+has no effect", while A.18.18(52/3) says "If Target denotes the same object as
+Source, then Move has no effect". They should use the same formula (no personal
+preference). A.18.10 seems to have the same kind of inconsistency.
+
+A.18.18(58.a/3) alludes to a documentation requirement, but there is no such
+thing.
+
+A.18.19(12/3) says: "(note that distinct elaborations of a type declaration
+result in distinct types)". This has nothing to do in normative text.
+
+A.18.20(11/3): otherwise, the operation propagate[d]{s} Capacity_Error (or
+better: "otherwise, Capacity_Error is propagated", but same change needed to
+12/3 and 13/3)
+
+A.18.20(16/3): same remark as A.18.19(12/3)
+
+A.18.21(17/3): same remark as A.18.19(12/3)
+
+A.18.22(14/3): same remark as A.18.19(12/3)
+
+A.18.23(17/3): same remark as A.18.19(12/3)
+
+A.18.24(14/3): same remark as A.18.19(12/3)
+
+A.18.25(16/3): same remark as A.18.19(12/3)
+
+A.18.26(9.3/3) says that "The generic formal Before compares the elements having
+the given indices", but does not explicitely say that it returns True if Left is
+to be sorted before Right.
+
+A.18.26: there is no implementation advice pertaining to
+Containers.Generic_Sort. Shouldn't it also be O(N**2)? And shouldn't it say that
+the number of calls to Swap should be minimized ?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April  5, 2011  12:32 AM
+
+> Here is my homework:
+>
+> A.18.17(7/3) made me look at A.18.10(109/3) which says: "if
+> element_type is ... definite", which is a bit strange since
+> Element_Type is necessarily definite.
+
+Right, but that is consistent with the other containers. A.18.2(142/2),
+A.18.3(86/2), A.18.4(41/2), and many more say the same thing. I suspect that it
+is foreshadowing for the rule here.
+
+So I'm not going to make a change.
+
+> A.18.18(45/3): shouldn't the Container parameter to Update_Element be
+> "in out"?  although it can be implemented as "in" because of hidden
+> pointers, other containers have it as "in out" (and it is logically
+> "in out").
+
+Yes, that's clearly a bug. Operations that modify a container always have an "in
+out" container parameter, whether it needs that mode or not.
+
+> A.18.18(48/3) says "If Target denotes the same object as Source, the
+> operation has no effect", while A.18.18(52/3) says "If Target denotes
+> the same object as Source, then Move has no effect". They should use
+> the same formula (no personal preference). A.18.10 seems to have the
+> same kind of inconsistency.
+
+Sure wish you had noticed that a long time ago. All of the newly added Assign
+routines have this wording. And all of the Move routines have this wording as
+well. So I have to redo all of one of them (I chose Move, since we had already
+decided to remove other examples of "Move" in them). Grumble.
+
+> A.18.18(58.a/3) alludes to a documentation requirement, but there is
+> no such thing.
+
+Implementation Advice always requires documenting when you don't follow it. (See
+Annex M.3.) So there is a documentation requirement.
+
+> A.18.19(12/3) says: "(note that distinct elaborations of a type
+> declaration result in distinct types)". This has nothing to do in
+> normative text.
+
+You are quite right. Again, it's annoying that no one caught it sooner, given
+that it appears in a half dozen or so places. Sigh.
+
+> A.18.20(11/3): otherwise, the operation propagate[d]{s} Capacity_Error
+> (or better: "otherwise, Capacity_Error is propagated", but same change
+> needed to 12/3 and 13/3)
+
+It wouldn't be better that much better, as there are plenty of uses of
+"propagates" throughout A.18. Admittedly, "propagated" is used much more, but it
+doesn't seem worth trying to reword 20+ paragraphs to get rid of this use.
+
+Also, this is a typo just in the draft RM; the AI and Amendment document are
+correct.
+
+...
+> A.18.26(9.3/3) says that "The generic formal Before compares the
+> elements having the given indices", but does not explicitely say that
+> it returns True if Left is to be sorted before Right.
+
+None of the sorting routines really say that, although the "<" ones say
+something about "smallest first", which I suppose is slightly more information.
+
+I added "; Before should return True if Left is to be sorted before Right." here
+and in the Queue containers (which also use Before). Not at all sure that that
+is appropriate wording, but I don't have any ideas.
+
+> A.18.26: there is no implementation advice pertaining to
+> Containers.Generic_Sort. Shouldn't it also be O(N**2)? And shouldn't
+> it say that the number of calls to Swap should be minimized ?
+
+I think so; I added similar sentences to A.18.26(10-11/2). (Neither can be
+exactly the same, 10/2 talks about "the Container" and 11/2 talks about copying
+rather than calls to Swap.)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, April  5, 2011  1:05 AM
+
+> Sure wish you had noticed that a long time ago.
+...
+> You are quite right. Again, it's annoying that no one caught it
+> sooner,
+...
+I guess it shows the value of having several reviews with different reviewers!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April  5, 2011  2:03 AM
+
+...
+> I guess it shows the value of having several reviews with
+> different reviewers!
+
+Yup, which is why we're going to do at all again next month. Not that I'm
+looking forward to dealing with more detailed reviews...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 30, 2010 11:53 AM
+
+> I'm starting to work on the review assignments for the upcoming
+> RM/AARM review. This will be an overall review of the consolidated
+> RM/AARM for problems. Reviews will need to be completed well before
+> the next ARG meeting (by October 15th) so that any major problems
+> uncovered can be put on the agenda for that meeting.
+
+Review of new RM/AARM Annex B.
+
+B.3(62.2/3): "which" --> "that"
+
+Sorry -- I couldn't find any real problems with this Annex.  ;-)
+
+General comment:  The changes are marked by color.  Maybe I missed it, but I
+didn't see a description of which color means what.  Would be good to have that
+in an early place. Seems like:
+
+    pink -- corrigendum (i.e. "Ada 95 and a half")
+    blue -- Ada 2005
+    orange -- Ada 2012
+
+When I print it out, pink and orange are nearly indistinguishable to my poor
+eyesight (although I can see it on the screen). Could you pick a different color
+for pink or orange?
+
+Better yet: why do we need to keep all this detailed history?  The "/n"
+paragraph numbers contain the info if it's really needed.  How about everything
+in black, with Ada 2012 changes in blue or green?  (Pink and orange are pretty
+garish, especially when it fills an entire page.)
+
+****************************************************************
+
+From: Bill Thomas
+Sent: Saturday, October 16, 2011  11:35 AM
+
+My comments on A.18.27 -> A.18.32:
+
+A.18.28, 3/3: This is the unbounded synchronized queue, so the Capacity discriminant
+in the type isn't needed
+
+A.18.30, 3/3: same comment, as this is the unbounded case for priority queues.
+
+A.18.30, 16/3: I suggest moving this sentence to appear before the descriptions of
+the Enqueue and Dequeue functions (i.e., right after 13/3)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April  6, 2011  9:11 PM
+
+...
+> My comments on A.18.27 -> A.18.32:
+>
+> A.18.28, 3/3: This is the unbounded synchronized queue, so
+> the Capacity discriminant in the type isn't needed
+
+I don't see this in the current version; perhaps it was already fixed.
+
+> A.18.30, 3/3: same comment, as this is the unbounded case for
+> priority queues.
+
+This only appears in the RM, not the Amendment, so I'll fix it but it won't appear
+in the AI.
+
+> A.18.30, 16/3: I suggest moving this sentence to appear
+> before the descriptions of the Enqueue and Dequeue functions
+> (i.e., right after 13/3)
+
+Good idea, done.
+
+****************************************************************
+
+From: Christoph Grein
+Sent: Tuesday, April 5, 2011  4:49 AM
+
+Generally the term "nonstandard" is used, also in the index. However at the
+following places, "non-standard" is used:
+
+3.5.2(9.n/2)
+A.3.2(60.e/2)
+D.1(29)
+
+I think it should be replaced, especially so since "non-standard" is not in the index.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Friday, October 8, 2010  9:03 AM
+
+My reading of Annex C and D only generated two code layout typos
+
+Code in D.2.1 (1.2/3 etc) has a slight alignment problem
+
+D.13.1 4/2, last line of pragma Restrictions looks wrong, perhaps this line is too
+long to fit, if so it would look better if the full column is moved to the left until
+it does fit.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April 6, 2011  9:59 PM
+
+...
+> My reading of Annex C and D only generated two code layout typos
+>
+> Code in D.2.1 (1.2/3 etc) has a slight alignment problem
+
+Just in the standard draft, so I've fixed it there without mentioning it in any AI.
+
+> D.13.1 4/2, last line of pragma Restrictions looks wrong, perhaps this
+> line is too long to fit, if so it would look better if the full column
+> is moved to the left until it does fit.
+
+It looks like it should have fit, but obviously it didn't. I've just changed the
+indentation a bit; I'm supposed to move this entire clause and when that is done
+the correction will get made in the new version.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, October 2, 2010  2:57 PM
+
+>            Brad Moore              Annex E-F, Annex H through Q
+
+My comments are:
+
+10.2.1 defines "program" as a set of partitions
+10.2.2 defined "partition" as a program or part of a program.
+
+These definitions are a bit circular. Is that OK?
+I think the intent is that a program must consist of at least one partition,
+perhaps thats not clear here.
+
+10.2.1(11.2/3)
+
+• {AI05-0028-1} The partial view of a private type or private extension, a
+protected type without entry_declarations, a generic formal private type, or a
+generic formal derived type, has preelaborable initialization if and only if the
+pragma Preelaborable_Initialization has been applied to {the partial
+view}[them].
+
+"them" is plural, yet the subject is singular.
+
+
+E.2.2(14.1/3) “implementation  kind” => “implementation kind” (i.e., only one
+space instead of two.)
+
+
+E.2.2(14.1/3) Feels like there should be an explanation here. (Either an AARM
+note, or a note) Why is "By_Any" only allowed for implementation_kind? I believe
+this is discussed in the AI, but would not be obvious to readers of the RM.
+
+
+E 2.2(20.b/2) “The wording was changed from “user-specified” to “available”
+{Read and Write} attributes”
+
+E 2.3(20.b/2) “The wording was changed from “user-specified” to “available”
+{Read and Write} attributes”
+
+E.3 (1.a) “The rules guarantee that remote call interface and shared library
+[packages]{library units} ...”
+
+E.4 (7/3) States that Remote Types and RCI library units define the remote
+subprograms used for remote subprogram calls. Shared Passive library units also
+define remote subprograms, and pure declared library units can also be used for
+this purpose. Shouldn't these be mentioned here also?
+
+I think this ties into
+22.d/3{AI05-0101-1} Correction: Corrected the text to note that remote access
+types can be defined in remote types units.
+
+I think the intent may have been that E.4(7/3) was modified so that remote
+access types can be defined in remote types units, but I don't think the wording
+changes accomplishes that.
+
+
+E.5(21.a) “[It is defined by tbe]{The} PCS implementation {defines} whether”
+
+
+F.3.2(73) {Result: }”bbb$***123,456.78”
+
+
+F.3.5(6.a/2) [(Shouldn't it have been “Widest_Text_IO.Editing”? :-)]
+
+
+H.4(24) No_Unchecked_Deallocation, No_Unchecked_Conversion, are obsolescent (See
+J.13) Should they still be mentioned here? Should the Restriction that replaced
+these, No_Dependence, be mentioned here as well, or instead? I would think it
+would be difficult for a compiler to support the No_Dependence for arbitrary
+packages to be eliminated from the run time.
+
+
+I note that AI05-189 No_Allocators_After_Elaboration will impact this section of
+the RM, however I presume it is not showing up in the RM yet, because the AI
+needs more work, and has not made its way to WG9 approval yet.
+
+
+J.2 (5.e) “is not legal in Ada 83, nor will it be in Ada 95.” This should be
+revised, it suggests Ada95 does not exist yet, and doesn't explain the situation
+for Ada 2005, Ada 2012, or the future.
+
+
+K(95/3) “{S'Class'Input first}[First] reads the external tag from Stream....”
+This sentence is missing a subject.
+
+“... and then dispatches to the subprogram denoted by the Input attribute of
+
+the specific type identified by the internal tag[;]{and subsequently} returns
+that result.”
+
+
+K(168/2) “{S'Class'Output first}[First] writes the external tag....” This
+sentence is missing a subject.
+
+K(194) “{S'Class'Read dispatches}[Dispatches]”
+
+
+K(273/2), K(277.4/2) Why was “image” changed from italicized to non-italicized
+in K(273/2), but left as italicized in K(277.4/2)? Also, “that is, a sequence of
+characters representing the value in display form.” was deleted from the first
+paragraph, but left intact in the second paragraph? Why the inconsistency?
+
+
+K(285) “S'Class'Write dispatches[Dispatches]”
+
+
+L(39.a) We have wording changes from Ada 83, but nothing since, yet there have
+been numerous other changes from Ada 95, Ada 2005, and Ada 2012. Should these be
+mentioned here? Annex K for instance doesn't mention any wording changes.
+
+
+M(1/2) “The Ada language allows for certain target machine dependences {to
+exist} in a controlled manner.” Sentence doesn't read well without addition.
+
+M.1  It seems surprising, (and questionable) that there have been no new
+documentation requirements added to this section for Ada 2012. Are we confident
+that none should have been added?
+
+e.g. Barrier_Limit in Ada.Synchronous_Barriers is missing, though perhaps this
+should not be mentioned here, but mentioned in M.2 instread (to be consistent
+with where System.Multiprocessors.CPU_Range was added). In any case, it is
+missing.
+
+
+M.2 Similarly, I would have thought there might be more additions than
+indicated.
+
+
+M.3(12/2) Doesn't read well, then sentence appears to be missing a subject.
+
+
+M.3 (84/2) (86/2) (87/2) (88/2) seems to be redundant with M.3(116/2), (118/2)
+
+
+N (26) says “A program may contain just one partition.” Can it be zero
+partitions? Wouldn't it be more accurate to say; “A program must contain at
+least one partition.”?
+
+
+P (6.1) parameter_specification, should be a space between [aliased]mode
+
+
+P (7.1) Says package specifications can have aspect specifications. AI 183 says
+this also, but gives no examples of use. Has this been specified well enough?
+For example, what does precondition, postconditions mean for a package
+specification. When are they executed? The rules appear to be covered by
+13.3.1(13/3) "Other rules are not defined at this time."
+
+
+Q.3(Language Defined Subprograms) I note that Language and Country from
+Ada.Locales does not show up here. Also Number_Of_CPUs from
+System.Multiprocessors is missing. Should there be a scrub through all the new
+packages to verify that all the new subprograms have been added?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April  7, 2011 12:51 PM
+
+...
+> >            Brad Moore              Annex E-F, Annex H through Q
+> My comments are:
+>
+> 10.2.1 defines "program" as a set of partitions
+> 10.2.2 defined "partition" as a program or part of a program.
+>
+> These definitions are a bit circular. Is that OK?
+> I think the intent is that a program must consist of at least one
+> partition, perhaps thats not clear here.
+
+This is probably not the best definition. But it is not something that was
+changed in Ada 2012, it doesn't seem very important, and trying to redefine this
+is more likely to introduce bugs than fix anything. So I'm inclined not to
+change anything. You're welcome to bring it up at the phone meeting or by a
+formal request on the ARG list if you think it is worth addressing.
+
+> 10.2.1(11.2/3)
+>
+> • {AI05-0028-1} The partial view of a private type or private
+> extension, a protected type without entry_declarations, a generic
+> formal private type, or a generic formal derived type, has
+> preelaborable initialization if and only if the pragma
+> Preelaborable_Initialization has been applied to {the partial
+> view}[them].
+>
+> "them" is plural, yet the subject is singular.
+
+This change is clearly wrong, since "them" is saying that the pragma can be
+applied to all four of the previous things. In any case, AI05-0229-1 totally
+rewrites this part of the standard, so this is OBE.
+
+> E.2.2(14.1/3) “implementation  kind” => “implementation kind”
+> (i.e., only one space instead of two.)
+
+That's "implementation_kind", that is, that is an underscore, not a space.
+That's hard to see in RM versions that show insertions and deletions.
+
+> E.2.2(14.1/3) Feels like there should be an explanation here.
+> (Either an AARM note, or a note) Why is "By_Any" only allowed for
+> implementation_kind? I believe this is discussed in the AI, but would
+> not be obvious to readers of the RM.
+
+This sentence should be changed by AI05-0215-1, of course (there is no pragma
+Implemented anymore), but it doesn't seem to be. I've put it on my discussion
+issues for tomorrow. Adding an AARM Reason seems reasonable, adding a user Note
+is over the top.
+
+> E 2.2(20.b/2) “The wording was changed from “user-specified”
+> to “available” {Read and Write} attributes”
+>
+> E 2.3(20.b/2) “The wording was changed from “user-specified”
+> to “available” {Read and Write} attributes”
+
+As AARM notes, these don't show up in the Amendment document.
+
+> E.3 (1.a) “The rules guarantee that remote call interface and shared
+> library [packages]{library units} ...”
+
+"library library"? :-)
+Same note as above.
+
+> E.4 (7/3) States that Remote Types and RCI library units define the
+> remote subprograms used for remote subprogram calls. Shared Passive
+> library units also define remote subprograms, and pure declared
+> library units can also be used for this purpose. Shouldn't these be
+> mentioned here also?
+
+No, those aren't "remote access types" or "remote subprograms", those things
+have formal definitions. An access type declared in a pure unit is surely not a
+remote access type or remote subprogram (indeed, I think such packages are
+supposed to be replicated, so there is nothing remote going on there).
+
+> I think this ties into
+> 22.d/3{AI05-0101-1} Correction: Corrected the text to note that remote
+> access types can be defined in remote types units.
+>
+> I think the intent may have been that E.4(7/3) was modified so that
+> remote access types can be defined in remote types units, but I don't
+> think the wording changes accomplishes that.
+
+The formal definition of a remote access type is an access type declared in a
+remote types package. E.2.1(9/3)! Someone pointed out that this statement didn't
+include the source of remote access types, which seemed wrong. But those don't
+come from other kinds of packages.
+
+> E.5(21.a) “[It is defined by tbe]{The} PCS implementation {defines}
+> whether”
+
+Ancient history and insufficiently broken.
+
+> F.3.2(73) {Result: }”bbb$***123,456.78”
+
+OK.
+
+> F.3.5(6.a/2) [(Shouldn't it have been “Widest_Text_IO.Editing”? :-)]
+
+Sorry, you don't get to remove the editor's jokes. If I tried to remove Bob's
+jokes, I *know* I'd be in trouble.
+
+> H.4(24) No_Unchecked_Deallocation, No_Unchecked_Conversion, are
+> obsolescent (See J.13) Should they still be mentioned here? Should the
+> Restriction that replaced these, No_Dependence, be mentioned here as
+> well, or instead? I would think it would be difficult for a compiler
+> to support the No_Dependence for arbitrary packages to be eliminated
+> from the run time.
+
+I think this should be wording in terms of particular No_Dependence restrictions
+(as was done in Ravenscar). It certainly should not be talking about obsolescent
+restrictions. But as this is a substansive change, I'll have to put it on our
+discussion list.
+
+> I note that AI05-189 No_Allocators_After_Elaboration will impact this
+> section of the RM, however I presume it is not showing up in the RM
+> yet, because the AI needs more work, and has not made its way to WG9
+> approval yet.
+
+There were a lot of such things. It was added to H.4(23.3/3); if something more
+needs to be done, hopefully the next reviewer will catch it.
+
+> J.2 (5.e) “is not legal in Ada 83, nor will it be in Ada 95.”
+> This should be revised, it suggests Ada95 does not exist yet, and
+> doesn't explain the situation for Ada 2005, Ada 2012, or the future.
+
+There is no value to mentioning language versions here. Replace with:
+
+is not legal in Ada (and never was legal). One has to write:
+
+> K(95/3) “{S'Class'Input first}[First] reads the external tag from
+> Stream....” This sentence is missing a subject.
+
+Doesn't matter. These sentences are automatically generated from the text that
+occurs elsewhere in the standard, and cannot be changed without changing the
+normative text elsewhere. It's a stupid design, but we're stuck with it.
+
+If you can justify changing the normative description of one of these
+attributes, then it *might* be possible to change this description. Do that
+wherever the attributes are defined. I'm not going to try, but you are welcome
+to if you care enough.
+
+> “... and then dispatches to the subprogram denoted by the Input
+> attribute of
+>
+> the specific type identified by the internal tag[;]{and subsequently}
+> returns that result.”
+>
+>
+> K(168/2) “{S'Class'Output first}[First] writes the external tag....”
+> This sentence is missing a subject.
+>
+> K(194) “{S'Class'Read dispatches}[Dispatches]”
+>
+>
+> K(273/2), K(277.4/2) Why was “image” changed from italicized to
+> non-italicized in K(273/2), but left as italicized in K(277.4/2)?
+> Also, “that is, a sequence of characters representing the value in
+> display form.” was deleted from the first paragraph, but left intact
+> in the second paragraph? Why the inconsistency?
+>
+>
+> K(285) “S'Class'Write dispatches[Dispatches]”
+
+> L(39.a) We have wording changes from Ada 83, but nothing
+> since, yet there have been numerous other changes from Ada
+> 95, Ada 2005, and Ada 2012. Should these be mentioned here?
+> Annex K for instance doesn't mention any wording changes.
+
+No, these are automatically generated annexes and I have no idea what changes
+have been made. And it makes no sense to spend a lot of time writing AARM notes
+that are next to useless anyway.
+
+> M(1/2) “The Ada language allows for certain target machine
+> dependences {to exist} in a controlled manner.” Sentence
+> doesn't read well without addition.
+
+That's Ada 95 wording.
+
+> M.1  It seems surprising, (and questionable) that there have
+> been no new documentation requirements added to this section
+> for Ada 2012. Are we confident that none should have been added?
+
+This section is only for "Documentation Requirements" sections. I did a quick
+check and did not find any added ones, but if there are any they should appear
+here.
+
+> e.g. Barrier_Limit in Ada.Synchronous_Barriers is missing,
+> though perhaps this should not be mentioned here, but
+> mentioned in M.2 instread (to be consistent with where
+> System.Multiprocessors.CPU_Range was added). In any case, it
+> is missing.
+
+Definitely it belongs in M.2, it's an "implementation-defined" item, not a
+direct "documentation requirement". I've added it.
+
+> M.2 Similarly, I would have thought there might be more
+> additions than indicated.
+
+Please find them. There is no automated way to look for these (any form of
+"implementation-defined" needs to be included), and I'm not about to read the
+entire standard for that! Please take an action item to look for these, and
+report any that are missing: by the section and paragraph where they are
+defined. (As an automated annex, I don't care about it at all, the changes need
+to be made elsewhere.)
+
+> M.3(12/2) Doesn't read well, then sentence appears to be
+> missing a subject.
+
+"For" is excess here. I just deleted it as I don't have a way to properly make a
+change here.
+
+> M.3 (84/2) (86/2) (87/2) (88/2) seems to be redundant with
+> M.3(116/2), (118/2)
+
+They're in different annexes. In any case, this clause intends to document every
+Implementation Advice section in the standard, so it seems likely that some
+would be redundant.
+
+> N (26) says “A program may contain just one partition.” Can
+> it be zero partitions? Wouldn't it be more accurate to say;
+> “A program must contain at least one partition.”?
+
+Probably, but we previously decided not to mess with the glossary, and this
+wording doesn't seem *wrong*.
+
+> P (6.1) parameter_specification, should be a space between
+> [aliased]mode
+
+P is completely automatically generated, can't make any changes here without
+changing the normative text. In any case, this doesn't appear in the current
+draft (presumably someone else noticed a problem in 6.1).
+
+> P (7.1) Says package specifications can have aspect
+> specifications. AI 183 says this also, but gives no examples
+> of use. Has this been specified well enough? For example,
+> what does precondition, postconditions mean for a package
+> specification. When are they executed? The rules appear to be
+> covered by 13.3.1(13/3) "Other rules are not defined at this time."
+
+This makes no sense. Aspects can only be specified on particular kinds of
+entities. For instance Pre is only allowed on a subprogram, Pure only on a
+package. In any case, AI05-0183-1 is *still* not finished, so it makes no sense
+to depend solely on the RM draft.
+
+> Q.3(Language Defined Subprograms) I note that Language and
+> Country from Ada.Locales does not show up here. Also
+> Number_Of_CPUs from System.Multiprocessors is missing. Should
+> there be a scrub through all the new packages to verify that
+> all the new subprograms have been added?
+
+That's done automatically, it's hard to miss them. If anything is missed, it's a
+markup error. Of course, those happen. So a scrub isn't a bad idea, I'm glad
+that you volunteered. :-) You'll find it on your next action item list. I did
+fix the ones you noted, of course.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent