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

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

--- ai05s/ai05-0248-1.txt	2011/04/07 06:29:32	1.2
+++ ai05s/ai05-0248-1.txt	2011/04/30 06:04:58	1.3
@@ -1,4 +1,6 @@
-!standard A.1(35)                                  11-04-06    AI05-0248-1/02
+!standard 11.4.1(10.1/2)                            11-04-28    AI05-0248-1/03
+!standard A.1(35)
+!standard A.4.10(0)
 !standard A.16(20)
 !standard A.16(82/2)
 !standard A.16.1(0)
@@ -7,11 +9,16 @@
 !standard A.18.2(147/2)
 !standard A.18.2(149/2)
 !standard A.18.2(239/2)
+!standard A.18.3(86/2)
 !standard A.18.3(88/2)
+!standard A.18.3(92/2)
+!standard A.18.3(94/2)
 !standard A.18.3(152/2)
+!standard A.18.4(41/2)
 !standard A.18.4(43/2)
 !standard A.18.4(75/2)
 !standard A.18.5(53/2)
+!standard A.18.7(36/2)
 !standard A.18.7(38/2)
 !standard A.18.7(96/2)
 !standard A.18.8(75/2)
@@ -55,11 +62,18 @@
 
 [Note: /3 paragraph numbers are from draft 11.]
 
+In 11.4.1(10.1/3), replace "For an occurrence originally raised for some other
+reason," with "For an occurrence originally raised in some other manner
+(including by the failure of a language-defined check),"
+
 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#)
 
+In A.4.10(0), remove "with Ada.Containers" whereever it appears (6 places), and
+change "To_String (Key)" to "To_String(Left), To_String (Right)" (4 places).
+
 Reformat A.16(20.1/3) to:
 
 type Name_Case_Kind is
@@ -92,6 +106,12 @@
 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(147.2/3), replace "Each element of Source is assigned to the
+corresponding element of Target." with
+"The elements of Source are then copied to Target as for an assignment_statement
+assigning Source to Target (this includes setting Target's length to be that of
+Source)."
+
 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."
@@ -101,6 +121,28 @@
 A.18.10(), and A.18.18(53/3) as follows: "...with elements of any <<container>>
 parameter [to] {of} the operation."
 
+In A.18.3(86.2/3), replace "Otherwise, it clears Target, and each element of
+Source is assigned to the corresponding element of Target." with "Otherwise, the
+elements of Source are copied to Target as for an assignment_statement assigning
+Source to Target."
+
+In A.18.3(92/2), A.18.3(94/2), A.18.10(143/3), and A.18.10(145/3), add "; if
+Count equals zero, then Constraint_Error is propagated."
+
+In A.18.4(41.2/3), replace "Otherwise, each key/element pair of Source is
+assigned to the corresponding key/element pair of Target." with "Otherwise, the
+key/element pairs of Source are copied to Target as for an assignment_statement
+assigning Source to Target."
+
+In A.18.7(36.2/3), replace "Otherwise, the elements of Source are
+assigned to the corresponding elements of Target." with "Otherwise, the
+element of Source are copied to Target as for an assignment_statement
+assigning Source to Target."
+
+In A.18.10(33/3), A.18.10(34/3), A.18.10(61/3), A.18.10(62/3),
+A.18.10(124/3), A.18.10(126/3), A.18.10(186/3), and A.18.10(190/3), delete
+the Container parameter.
+
 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:
@@ -120,18 +162,41 @@
 
 Modify A.18.10(94/3): "... designates the root node of [the] {some} tree; ..."
 
+In A.18.10(111/3), replace "Otherwise, it calls Clear (Target), and then each
+element of Source is assigned to a corresponding element in Target." with
+"Otherwise, the elements of Source are copied to Target as for an
+assignment_statement assigning Source to Target."
+
+In A.18.10(124/3), A.18.10(126/3), A.18.10(188/3), and A.18.10(192/3), delete
+"; if Position does not designate a node in Container, then Program_Error is
+propagated".
+
 Modify A.18.10(131/3): "... if the cursor designates [the] {a} root node ..."
 
+Modify A.18.10(135/3): "... with the cursors of {the tree containing
+Position}[Container]."
+
 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(155/3): "... If Source denotes the same object as Target, then{:
+if Position equals Before there is no effect; if Position designates an ancestor
+of Parent or is equal to Parent, Constraint_Error is propagated;
+[else]{otherwise}, ..."
+
+Modify A.18.10(158/3): "If Position equals No_Element [or designates a root node],
+Constraint_Error is propagated. If Position does not designate a node in
+Container {or designates a root node}, then Program_Error is propagated.
 
 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 ..."
 
+Modify A.18.10(189/3 and 193/3): "... with the cursors of {the tree
+containing Parent}[Container]."
+
+
 Move paragraph A.18.30(17/3) after A.18.30(14/3).
 
 Modify A.19(1/3): "... internationalization{-}related characteristics."
@@ -177,12 +242,58 @@
 understandability, but are not intended to change the meaning of the words,
 except in the case of clear mistakes. The latter are listed below:
 
+Unnecessary withs were removed from A.4.10. The description of these operations
+was corrected to use the two defined parameters instead of "Key".
+
+Insert routines for lists and trees now raise Constraint_Error if the Count
+is zero and a cursor designating the inserted element is expected. We could
+have returned No_Element instead, but that violates the postcondition that
+Position points at a newly inserted element and probably would lead to either
+extra checks of the result or a crash.
+
+A.18.10(155/3) and A.18.10(158/3) were rewritten to be consistent with each
+other and the rest of the Tree container. Different results will happen in
+some error cases.
+
+Unnecessary Container parameters were removed from Find_In_Subtree,
+Ancestor_Find, Iterate_Children, and Reverse_Iterate_Children.
+
 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 11.4.1(10.1/2)
+
+@drepl
+Exception_Message returns the message associated
+with the given Exception_Occurrence. For an occurrence raised by a call to
+Raise_Exception, the message is the Message parameter passed to Raise_Exception.
+For the occurrence raised by a @fa<raise_statement> with an
+@I<exception_>@fa<name> and a @I<string_>@fa<expression>, the message is
+the @i<string_>@fa<expression>. For the occurrence raised by a
+@fa<raise_statement> with
+an @i<exception_>@fa<name> but without a @i<string_>@fa<expression>,
+the message is a string giving implementation-defined information about the
+exception occurrence. In all cases, Exception_Message returns a string with
+lower bound 1.
+@dby
+Exception_Message returns the message associated
+with the given Exception_Occurrence. For an occurrence raised by a call to
+Raise_Exception, the message is the Message parameter passed to Raise_Exception.
+For the occurrence raised by a @fa<raise_statement> with an
+@I<exception_>@fa<name> and a @I<string_>@fa<expression>, the message is
+the @i<string_>@fa<expression>. For the occurrence raised by a
+@fa<raise_statement> with
+an @i<exception_>@fa<name> but without a @i<string_>@fa<expression>,
+the message is a string giving implementation-defined information about the
+exception occurrence. For an occurrence originally raised
+in some other manner (including by the failure of a language-defined check),
+the message is an unspecified string. In all cases, Exception_Message returns
+a string with lower bound 1.
+
+
 !corrigendum A.1(35/2)
 
 @dprepl
@@ -191,6 +302,12 @@
 @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.4.10(0)
+
+@dinsc
+
+Force a conflict; real text found in the conflict file.
+
 !corrigendum A.16(20/2)
 
 @dinsa
@@ -260,7 +377,9 @@
 @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.>
+The elements of Source are then copied to Target as for an
+@fa<assignment_statement> assigning Source to Target (this includes
+setting Target's length to be that of Source).>
 
 !corrigendum A.18.2(149/2)
 
@@ -292,6 +411,23 @@
 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(86/2)
+
+@dinsa
+@xindent<If Element_Type is unconstrained and definite, then the actual Element parameter of
+Process.@b<all> shall be unconstrained.>
+@dinss
+@xcode<@b<procedure> Assign (Target : @b<in out> List; Source : @b<in> List);>
+
+@xindent<If Target denotes the same object as Source, the operation has no
+effect. Otherwise, the elements of Source are copied to Target as for an
+@fa<assignment_statement> assigning Source to Target.>
+
+@xcode<@b<function> Copy (Source : List) @b<return> List;>
+
+@xindent<Returns a list whose elements match the elements of Source.>
+
+
 !corrigendum A.18.3(88/2)
 
 @drepl
@@ -301,6 +437,44 @@
 @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(92/2)
+
+@drepl
+@xindent<If Before is not No_Element, and does not designate an element in
+Container, then Program_Error is propagated. Otherwise, Insert allocates Count
+copies of New_Item, and inserts them prior to the element designated by Before.
+If Before equals No_Element, the new elements are inserted after the last
+element (if any). Position designates the first newly-inserted element. Any
+exception raised during allocation of internal storage is propagated, and
+Container is not modified.>
+@dby
+@xindent<If Before is not No_Element, and does not designate an element in
+Container, then Program_Error is propagated; if Count equals zero, then
+Constraint_Error is propagated. Otherwise, Insert allocates Count
+copies of New_Item, and inserts them prior to the element designated by Before.
+If Before equals No_Element, the new elements are inserted after the last
+element (if any). Position designates the first newly-inserted element. Any
+exception raised during allocation of internal storage is propagated, and
+Container is not modified.>
+
+!corrigendum A.18.3(94/2)
+
+@drepl
+@xindent<If Before is not No_Element, and does not designate an element in
+Container, then Program_Error is propagated. Otherwise, Insert inserts Count new
+elements prior to the element designated by Before. If Before equals No_Element,
+the new elements are inserted after the last node (if any). The new elements are
+initialized by default (see 3.3.1). Any exception raised during allocation of
+internal storage is propagated, and Container is not modified.>
+@dby
+@xindent<If Before is not No_Element, and does not designate an element in
+Container, then Program_Error is propagated; if Count equals zero, then
+Constraint_Error is propagated. Otherwise, Insert inserts Count new
+elements prior to the element designated by Before. If Before equals No_Element,
+the new elements are inserted after the last node (if any). The new elements are
+initialized by default (see 3.3.1). Any exception raised during allocation of
+internal storage is propagated, and Container is not modified.>
+
 !corrigendum A.18.3(152/2)
 
 @dinsa
@@ -316,6 +490,18 @@
 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(41/2)
+
+@dinsa
+@xindent<If Element_Type is unconstrained and definite, then the actual Element parameter of
+Process.@b<all> shall be unconstrained.>
+@dinst
+@xcode<@b<procedure> Assign (Target : @b<in out> Map; Source : @b<in> Map);>
+
+@xindent<If Target denotes the same object as Source, the operation has no
+effect. Otherwise, the key/element pairs of Source are copied to Target as
+for an @nt{assignment_statement} assigning Source to Target.>
+
 !corrigendum A.18.4(43/2)
 
 @drepl
@@ -355,6 +541,21 @@
 greater than the capacity of Target, Reserve_Capacity (Target, Length (Source)) is called
 before assigning any elements.>
 
+!corrigendum A.18.7(36/2)
+
+@dinsa
+@xindent<If Position equals No_Element, then Constraint_Error is propagated.
+Otherwise, Query_Element calls Process.@b<all> with the element designated by
+Position as the argument. Program_Error is propagated if Process.@b<all>
+tampers with the elements of Container. Any exception raised by
+Process.@b<all> is propagated.>
+@dinss
+@xcode<@b<procedure> Assign (Target : @b<in out> Set; Source : @b<in> Set);>
+
+@xindent<If Target denotes the same object as Source, the operation has no
+effect. Otherwise, the elements of Source are copied to Target as
+for an @fa<assignment_statement> assigning Source to Target.>
+
 !corrigendum A.18.7(38/2)
 
 @drepl
@@ -950,6 +1151,875 @@
 
 ****************************************************************
 
+From: Tullio Vardanega
+Sent: Saturday, October  9, 2010  2:12 PM
+
+  9.3(7/2, 8)
+the style used elsewhere for lists takes lowercase initials; cf. for example
+note 12 below on the same page
+
+9.5.1(30)
+the Count attribute is referred to without being first defined (in fact, its
+first occurrence is at 8.5.4(11)); it should probably need a forward reference
+to 9.9(5)
+
+9.6.1(6/2)
+function UTC_Time_Offset (Date
+should be
+function UTC_Time_Offset(Date
+i.e. no space before open bracket
+
+9.6.1(12/2)
+procedure Difference (Left
+should be
+procedure Difference(Left
+i.e. no space before open bracket
+
+9.6.1(13/2)
+the declaration of all functions at this clause should be have one space less
+before the first open bracket
+
+9.6.1(15/2)
+the declaration of all subprograms in package Ada.Calendar.Formatting should be
+have one space less before the first open bracket
+
+9.6.1(41/2)
+function UTC_Time_Offset (Date
+should be
+function UTC_Time_Offset(Date
+
+9.6.1(43/2)
+procedure Difference (
+should be
+procedure Difference(
+and the subsequent three lines retracted by one space
+
+all subsequent subprograms until 87/2 should be fixed the same way
+
+9.7.4(8)
+the asynchronous_select is complete.
+should probably be
+the asynchronous_select is completed.
+
+9.11
+when trying to put together the example I have noticed that type Month_Name
+referred to at 3.8(27) is never defined anywhere in the RM
+
+in the same example, it should be good that type Person_Name_Array was
+explicitly defined
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 19, 2011 12:04 AM
+
+>   9.3(7/2, 8)
+> the style used elsewhere for lists takes lowercase initials; cf. for
+> example note 12 below on the same page
+
+There is no consistent style for bulleted lists in the Ada Standard. Case in
+point: 9.3, where your can find three styles for a bulleted list (para 2-3.1
+uses capitals and periods; para 7-8 uses capitals, semicolons, "and"; para 15-18
+uses lower case and semicolons, no "or" or "and"). Looking at 9.4, we see para
+11.6-7 using lower case, semicolons, and "or"; para 11.11-12 using lower case,
+semicolons, no "or" or "and"; para 17-18 using capitals and semicolons, no "or"
+or "and". See any commonality there? :-)
+
+Given the intent to not mess with "old bugs", we're not going to try to make
+these consistent now at this late date.
+
+> 9.5.1(30)
+> the Count attribute is referred to without being first defined (in
+> fact, its first occurrence is at 8.5.4(11)); it should probably need a
+> forward reference to 9.9(5)
+
+You mean 9.5.2(30). Both of these references are Notes, so I don't feel terribly
+compelled to put in a forward reference; and again this is ancient.
+
+> 9.6.1(6/2)
+> function UTC_Time_Offset (Date
+> should be
+> function UTC_Time_Offset(Date
+> i.e. no space before open bracket
+
+Huh? The format the Standard always has a space between the subprogram name and
+the parameter list.
+
+Calendar and other ancient packages occasionally violate the style, but not so
+with new packages.
+
+...
+> 9.7.4(8)
+> the asynchronous_select is complete.
+> should probably be
+> the asynchronous_select is completed.
+
+I'm not sure. I think it is referring to the term "complete" as defined in
+7.6.1(1). "Completed" seems to me to imply some action occurring, whereas this
+case is just stating a fact. So I think this is insufficiently broken to bother
+fixing.
+
+> 9.11
+> when trying to put together the example I have noticed that type
+> Month_Name referred to at 3.8(27) is never defined anywhere in the RM
+>
+> in the same example, it should be good that type Person_Name_Array was
+> explicitly defined
+
+Month_Name would have to declared in 3.5.1's examples, and it is a bit long for
+there.
+
+Person_Name_Array would probably have to go into 9.11, but it's primary purpose
+would be to highlight a flaw in Ada (the fact that you can't put types into
+protected types, and thus structuring protected types is a real pain). Not sure
+that is a good idea.
+
+I'm sympathetic, especially for the latter (as this was a new example added at
+the last minute to Ada 2005). But I worry that some would see it as cluttering
+the example.
+
+Does anyone else have an opinion on this one??
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 19, 2011 11:18 AM
+
+> Person_Name_Array would probably have to go into 9.11, but it's
+> primary purpose would be to highlight a flaw in Ada (the fact that you
+> can't put types into protected types, and thus structuring protected
+> types is a real pain). Not sure that is a good idea.
+
+It would be a very good idea and help to highlight a real pain that needs to be
+sorted out. Maybe I jest. More important in my view than half the stuff actually
+put into Ada 2012.  Grumble grumble.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Saturday, October  9, 2010 10:41 AM
+
+My review assignment...
+
+==========================================
+
+10.2.1. 11/3 and 17/3  see separate mail entitled "[ARG] technical issue of
+prelaborated and pure limited views" on these two paragraphs.
+
+===========================================
+
+11.1 2/3  Formating: the aspect clause should not start a new line.
+
+===========================================
+
+11.4.1 10.1/3 penultimate sentence:
+> For an occurrence originally raised for some other reason, the message
+> is an unspecified string.
+
+lazy wording "for some other reason". In "if things-go-bump then raise fright;
+end if;" things-go-bump is the reason for the exception, not the raise
+statement.
+
+According to 11 2/3(2.sentence) only implicit raises are left. If indeed
+9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but presumably it is but a
+propagation and hence not an extra case. Footnote: I would prefer
+implementation-defined string. Oh well.
+
+Rewrite:
+-----
+For an occurrence originally raised by a language-defined check, the message is
+an unspecified string.
+
+===========================
+
+12.1 3/3  Formating: the aspect clause should not start a new line.
+
+==============================
+
+12.4 2/3  Formating: the aspect clause should not start a new line.
+
+==============================
+
+OLD BUG:
+12.4. 5/2 Delete the spurious second period at the end of the para.
+
+==============================
+
+12.5 2/3  Formating: the aspect clause should not start a new line.
+
+=============================
+
+Before 12.5.3. Strange "NewPage" mistake in formatting.
+
+============================
+
+12.6 2/3  Formating: the aspect clause should not start a new line.
+
+============================
+
+12.6. 10/3 is desperately in need of grammatical (and possibly
+conceptual) simplification. Also "this default_name" in the 2. sentence has no
+binding in the text at all.  The lead-in sentence talks about box not
+default_name.
+
+> If a generic unit has a subprogram_default specified by a box, and the
+> corresponding actual parameter is omitted, then it is equivalent to an
+> explicit actual parameter that is a usage name identical to the
+> defining name of the formal. If a subtype_mark in the profile of the
+> formal_subprogram_declaration denotes a formal private or formal
+> derived type and the actual type for this formal type is a class-wide
+> type T'Class, then for the purposes of resolving this default_name at
+> the point of the instantiation, for each primitive subprogram of T
+> that has a matching defining name, that is directly visible at the
+> point of the instantiation, and that has at least one controlling
+> formal parameter, a corresponding subprogram with the same defining
+> name is directly visible, but with T systematically replaced by
+> T'Class in the types of its profile. The body of such a subprogram is
+> as defined in 12.5.1 for primitive subprograms of a formal type when
+> the actual type is class-wide.
+
+I tried to rewrite, but discovered that I did not understand the fine points of
+the rule of the second sentence in the first place, which makes it hard to
+propose better wording.
+
+=================================
+
+12.7 2/3  Formating: the aspect clause should not start a new line.
+
+=================================
+
+12.7. 4.1/3 and 4.2/2  It is rather unfortunate that the paragraph number of the
+old 4.1/2 changed to 4.2/3. I suggest interchanging 4.1/2 and 4.2/3 to preserve
+the numbering. The logic could be that the rules are stated in the order of the
+productions.
+
+=================================
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 29, 2011 12:55 AM
+
+> My review assignment...
+> Erhard
+>
+> ==========================================
+>
+> 10.2.1. 11/3 and 17/3  see separate mail entitled "[ARG] technical
+> issue of prelaborated and pure limited views"
+> on these two paragraphs.
+
+That begat its own AI, which eventually became AI05-0243-1. Hopefully we got
+that right.
+
+> ===========================================
+>
+> 11.1 2/3  Formating: the aspect clause should not start a new line.
+
+Actually, that is the intended formatting for aspect clauses. At least, so says
+Tucker, and we've informally agreed that is what we want to do. (We've never
+discussed this at a meeting, though, only during one of the informal phone
+calls.)
+
+It's pretty much the only thing that would work for the syntax, because we can't
+just add these to the end of the productions, most of them are way too long.
+
+> ===========================================
+>
+> 11.4.1 10.1/3 penultimate sentence:
+> > For an occurrence originally raised for some other reason, the
+> > message is an unspecified string.
+>
+> lazy wording "for some other reason". In "if things-go-bump then raise
+> fright; end if;"
+> things-go-bump is the reason for the exception, not the raise
+> statement.
+
+Ugh, I suppose you are right.
+
+> According to 11 2/3(2.sentence) only implicit raises are left. If
+> indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but
+> presumably it is but a propagation and hence not an extra case.
+> Footnote: I would prefer implementation-defined string. Oh well.
+
+I don't quite buy this; anything that creates an occurrence has an
+Exception_Message; it doesn't have to come from a raise of an exception. In
+particular, it is possible to stream an occurrence, and I don't think the
+language intended to require that the message is preserved unchanged. (Some
+implementations truncate occurrences when they are copied or streamed; Janus/Ada
+does that as the stack information could take up a huge amount of space
+otherwise. Also, most exception messages are pointers (if static) until an
+occurrence is copied; at that point the string has to be copied into the
+occurrence [because we can't stream or do I/O on a pointer] and that truncates
+it).
+
+> Rewrite:
+> -----
+> For an occurrence originally raised by a language-defined check, the
+> message is an unspecified string.
+
+What about "new" occurrences from other source, at least WRT the current
+program? The Ada 2005 wording definitely left that unspecified -- maybe it was
+unintentional, but I don't want to change it without a full discussion (too late
+for that now, I think). And the Adam question (in AI05-0043-1) seems legitimate;
+9.5.2(24.b) says that this is a new occurrence; it is *not* considered
+propagation. (Of course, AARM notes can be wrong, but it shows an intent.)
+
+Indeed, I can't find anything that clearly says that propagation is required to
+preserve the information in an occurrence. It seems like that should be said
+somewhere. And I know that a reraise doesn't preserve an occurrence (at least in
+Janus/Ada, it preserves parts of it, but it changes to reflect the reraise
+location so that can be traced if necessary).
+
+All-in-all, I don't think this is well-specified, and it hardly is worth
+specifying much (do implementers really make these things useless because they
+can?? I think it is more likely that they have a good reason for whatever they
+do).
+
+So, I'm making a minor tweak to this wording:
+
+"For an occurrence originally raised in some other manner (including by the
+failure of a language-defined check), the message is an unspecified string."
+
+This isn't ideal, but this isn't worth a lot of effort, either.
+
+> ===========================
+>
+> 12.1 3/3  Formating: the aspect clause should not start a new line.
+
+Previously discussed.
+
+> ==============================
+>
+> 12.4 2/3  Formating: the aspect clause should not start a new line.
+
+Ibid.
+
+> ==============================
+>
+> OLD BUG:
+> 12.4. 5/2 Delete the spurious second period at the end of the para.
+
+Got it.
+
+> ==============================
+>
+> 12.5 2/3  Formating: the aspect clause should not start a new line.
+
+As previous.
+
+> =============================
+>
+> Before 12.5.3. Strange "NewPage" mistake in formatting.
+
+The "NewPage"s were inserted to make the Ada 2005 RM look good. They'll need to
+be moved for Ada 2012 when it is finished, but that is a last minute job --
+there's not much point in messing with them now.
+
+There's not a NewPage there, though, and I don't see anything weird in the
+current RM draft. So I can't do anything here.
+
+> ============================
+>
+> 12.6 2/3  Formating: the aspect clause should not start a new line.
+
+Getting tired of seeing this one. :-)
+
+> ============================
+>
+> 12.6. 10/3 is desperately in need of grammatical (and possibly
+> conceptual) simplification. Also "this default_name" in the 2.
+> sentence has no binding in the text at all.  The lead-in sentence
+> talks about box not default_name.
+>
+> > If a generic unit has a subprogram_default specified by a box, and
+> > the corresponding actual parameter is omitted, then it is equivalent
+> > to an explicit actual parameter that is a usage name identical to
+> > the defining name of the formal. If a subtype_mark in the profile of
+> > the formal_subprogram_declaration denotes a formal private or formal
+> > derived type and the actual type for this formal type is a
+> > class-wide type T'Class, then for the purposes of resolving this
+> > default_name at the point of the instantiation, for each primitive
+> > subprogram of T that has a matching defining name, that is directly
+> > visible at the point of the instantiation, and that has at least one
+> > controlling formal parameter, a corresponding subprogram with the
+> > same defining name is directly visible, but with T systematically
+> > replaced by T'Class in the types of its profile. The body of such a
+> > subprogram is as defined in 12.5.1 for primitive subprograms of a
+> > formal type when the actual type is class-wide.
+>
+> I tried to rewrite, but discovered that I did not understand the fine
+> points of the rule of the second sentence in the first place, which
+> makes it hard to propose better wording.
+
+Luckily, AI05-0131-1 undid these changes completely and put them into a separate
+paragraph. Of course, it is twice as long and probably not much of an
+improvement. :-) In any case, it absolves me of doing anything with this
+comment.
+
+> =================================
+>
+> 12.7 2/3  Formating: the aspect clause should not start a new line.
+
+Grumble.
+
+> =================================
+>
+> 12.7. 4.1/3 and 4.2/2  It is rather unfortunate that the paragraph
+> number of the old 4.1/2 changed to 4.2/3. I suggest interchanging
+> 4.1/2 and 4.2/3 to preserve the numbering. The logic could be that the
+> rules are stated in the order of the productions.
+
+This happens more often than you would think. I've been trying to ensure that
+all renumbered paragraphs have /3 numbers even if they aren't themselves
+changed. Beyond that, I don't think I want to go there -- this stuff is hard
+enough to understand without reordering it to keep paragraph numbers the same.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 30, 2010 11:52 AM
+
+>...Reviews will need to be completed well before the next ARG meeting
+>(by October 15th) ...
+
+Review of new RM/AARM Chapter 13.
+
+Thanks, Randy, for all your hard work on the new RM!
+
+My main comment is that it's a shame that Chap 13, "Representation Issues", has
+grown way beyond the low-level stuff it used to be about.  I wonder if it might
+be worthwhile to move stuff like Pre/Postconditions earlier in the RM.  The
+downside is that those rely on "aspect clauses", so there would be a forward
+reference.
+
+One possible solution would be to move aspect clauses earlier, too.
+We can say their primary purpose is stuff like pre/post (and oh, by the way,
+they can be used for Size clauses, too, but we don't mention that until chap
+13).
+
+Another solution would be to leave aspect clauses in chap 13, but move pre/post
+(etc.) earlier.  An intro paragraph that hints at the syntax could alleviate the
+forward reference problem:
+
+    This section defines precondition and postcondition aspects
+    for subprograms.  For example, a procedure can have
+    "with Pre => _some_condition_" to place a requirement
+    on callers.  Similarly, a procedure can indicate that
+    it ensures some condition by having "with Post =>
+    _some_condition_".
+
+Not quite the normal RM style, but maybe for once we could place clarity above
+the hobgoblin of little minds.  ;-)
+
+----------------
+
+Another point applies to the entire AARM.  I think there are way too many
+"Wording Changes from..." paragraphs.
+
+Reminder of history: Some reviewers of Ada 9X viewed the design team as a bunch
+of loose cannons, making gratuitous changes all over.  (Maybe they were right,
+maybe they were wrong, maybe some of both -- it's not my intent to re-debate
+that!) The main purpose of the "Wording Changes from Ada 83" sections was to
+(defensively) clarify that certain changes to the wording were not in fact
+changes to the language, and therefore did not require implementation effort,
+nor effort on the part of programmers to change their ways.
+
+A secondary intent was to give rationale (e.g.: we're defining a new word
+"elementary type", because we have a lot of new rules that involve those, and we
+don't want to say "scalar or access" all over -- and it simplifies some existing
+rule).
+
+There was never any intent to document every wording change.
+Only the potetially controversial ones, and ones that needed clarification.
+
+In particular, if an entire feature is new, we don't need blather on about how
+we added some definitions to support that feature's wording.
+
+My point is: I suggest removing "Wording Changes from Ada 2005"
+if they don't substantially add to understanding.  Note that the AI references
+are always there for language lawyers who want to research the gory details of
+such changes.
+
+Examples of paragraphs that could be profitably removed:
+
+    13.1(28.r/3-28.t/3)
+    13.3(21.c.1/3)
+    13.9.1(14.e/3)
+    13.11(43.h/3-43.j/3)
+    [Got tired of listing them.  Most of the ones in this
+     chapter seem devoid of useful information.  And they
+     have more than their fair share of typos...]
+
+----------------
+
+13.1(8/3): "Unless otherwise specified": I thought we had decided that the
+aspect and pragma names always match (so it's "Pack", not "packing".
+
+13.1(8.e.1/3): I suggest this para be deleted.  It's not really informative,
+especially if pragma names match aspect names (as they should).
+
+13.2(5): "A pragma Pack specifies the packing aspect of representation; the type
+(or the extension part) is said to be packed." "A type (or extension part) with
+the Pack aspect specified is said to be packed."
+
+13.3(11.1/3): This is already covered by 13.3(13/3).
+
+13.3(13/3): "and appropriate for the entity and its use"
+adds nothing of value.
+
+13.3(13.a): Same here.
+
+13.3.1(6/3): "} )" --> "})".
+
+13.3.1(11/3): "[ are" --> "[are".
+"point" --> "place" (we don't normally talk about "points" in this sense, I
+think). This notion of being resolved at a place (or point) seems overly
+implementation oriented.  Seems like we should instead say something like "The
+visibility of defining names in an aspect_definion is is as if it occured at the
+end...".
+
+13.3.1(12/3): Two occurrences of "visible" that I think should be "directly
+visible". Not sure why "sub" is in parens in "(sub)type" (last word).
+
+13.3.2(6/3): Doesn't fit in with 13.3.1(8/3), which is expecting us to define
+the type of the aspect, not again define the expected type for the expression.
+
+13.3.2(8/3): "independent of context" doesn't sound right.
+"independently"?  Anyway, shouldn't we be talking about the "single type" notion
+in 8.6(27/2)?
+
+13.9.1(14.e/3):
+
+    `Rosen trick"
+
+has mismatched quotes.  Also "squirreling" --> "squirreling away"
+Index entry for "squirrel away" should be updated.
+I'd delete this entire para, though.
+
+13.11(21.h/3): "which" --> "that"
+
+13.11(43.i/3): "specify the" --> "specify that the".
+
+13.11(43.j/3): "an allocators" singular or plural
+
+13.11.2(19.b/3): "It hard" --> "It is hard"
+
+13.12.1(2/2): Index entry refers to "_Pragmas_"; should be "_Attributes_".  (By
+the way, this is the first time I EVER recall making use of those in-line index
+"{...}" thingies!  Maybe they should be removed, even from the AARM.)
+
+13.13.2(52/3): "]" appears at start of line.  Maybe you could fix all these by
+doing a global search and making sure stray blanks don't sneak into the
+@redundant command or whatever it is.
+
+13.13.2(56.d/3): "which" --> "that"
+
+13.14(15.e/3): One does not "go" through hoops; one "jumps" through them.
+
+Whew!  That was a lot of work.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April  7, 2011  1:13 AM
+
+Replies to the general part of this.
+
+> Review of new RM/AARM Chapter 13.
+>
+> Thanks, Randy, for all your hard work on the new RM!
+
+Buttering me up before lowering the hammer... ;-)
+
+> My main comment is that it's a shame that Chap 13, "Representation
+> Issues", has grown way beyond the low-level stuff it used to be about.
+
+Blame that on the Ada 95 people who put the stream stuff into it. Those are not
+that low-level, and they drove the creation of the idea of "aspects", and that
+led to everything else.
+
+> I wonder if it might be
+> worthwhile to move stuff like Pre/Postconditions earlier in the RM.
+> The downside is that those rely on "aspect clauses", so there would be
+> a forward reference.
+
+And aspects themselves...
+
+> One possible solution would be to move aspect clauses earlier, too.
+> We can say their primary purpose is stuff like pre/post (and oh, by
+> the way, they can be used for Size clauses, too, but we don't mention
+> that until chap 13).
+
+The concept of aspects is introduced in 13.1; that would still be a major
+forward reference. And all of their general semantics is also there. And moving
+that too would be even more nasty.
+
+> Another solution would be to leave aspect clauses in chap 13, but move
+> pre/post (etc.) earlier.  An intro paragraph that hints at the syntax
+> could alleviate the forward reference
+> problem:
+>
+>     This section defines precondition and postcondition aspects
+>     for subprograms.  For example, a procedure can have
+>     "with Pre => _some_condition_" to place a requirement
+>     on callers.  Similarly, a procedure can indicate that
+>     it ensures some condition by having "with Post =>
+>     _some_condition_".
+>
+> Not quite the normal RM style, but maybe for once we could place
+> clarity above the hobgoblin of little minds.  ;-)
+
+But all of the semantics of aspects is not there either. This isn't just about
+aspect_specification syntax!!
+
+I think you are right in that an overall revision of the standard would surely
+move aspects much earlier and generalize the concept further. But we're *not*
+doing such a revision.
+
+So I don't think this is even a good idea. Maybe we'll be forced to do a full
+revision for Ada 2020; then such reorganization would be a good idea. I'll put
+it on the list of things to talk about tomorrow.
+
+> ----------------
+>
+> Another point applies to the entire AARM.  I think there are way too
+> many "Wording Changes from..." paragraphs.
+>
+> Reminder of history: Some reviewers of Ada 9X viewed the design team
+> as a bunch of loose cannons, making gratuitous changes all over.
+> (Maybe they were right, maybe they were wrong, maybe some of both --
+> it's not my intent to re-debate
+> that!) The main purpose of the "Wording Changes from Ada 83"
+> sections was to (defensively) clarify that certain changes to the
+> wording were not in fact changes to the language, and therefore did
+> not require implementation effort, nor effort on the part of
+> programmers to change their ways.
+>
+> A secondary intent was to give rationale (e.g.: we're defining a new
+> word "elementary type", because we have a lot of new rules that
+> involve those, and we don't want to say "scalar or access" all over --
+> and it simplifies some existing rule).
+>
+> There was never any intent to document every wording change.
+> Only the potetially controversial ones, and ones that needed
+> clarification.
+
+Right.
+
+> In particular, if an entire feature is new, we don't need blather on
+> about how we added some definitions to support that feature's wording.
+
+Right, but we do need to document that it is an extension somewhere else. I've
+repeatedly been asked why certain things are not documented as extensions, and
+the answer is always that it is documented somewhere else -- and we don't want
+to mark the same thing as an extension in dozens of places.
+
+> My point is: I suggest removing "Wording Changes from Ada 2005"
+> if they don't substantially add to understanding.  Note that the AI
+> references are always there for language lawyers who want to research
+> the gory details of such changes.
+
+There is also another purpose to these: they tell the difference between Binding
+Intepretations and Amendment class AIs. If I don't mention an AI either way,
+then you can only tell by looking in the AI (which is tough for most people -
+that don't have all of the AIs easily at hand - if you are not on line or not
+using the HTML version).
+
+This was added by popular request, and I had to add a lot of Wording Change
+sections that I otherwise wouldn't have bothered with.
+
+> Examples of paragraphs that could be profitably removed:
+>
+>     13.1(28.r/3-28.t/3)
+
+Nope: We need the "correction" tags.
+
+>     13.3(21.c.1/3)
+
+I think this is a critical change; it's missing from earlier versions of the
+standard.
+
+>     13.9.1(14.e/3)
+
+"Correction" tag again.
+
+>     13.11(43.h/3-43.j/3)
+>     [Got tired of listing them.  Most of the ones in this
+>      chapter seem devoid of useful information.  And they
+>      have more than their fair share of typos...]
+
+The typos are because I have to write them without any help from anyone else.
+And my view of English tends to be different than the textbooks would suggest.
+;-)
+
+-------------------
+
+I'll do the specific part some day soon.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 28, 2011 11:55 PM
+
+The remainder of Bob's editorial review:
+...
+> 13.1(8/3): "Unless otherwise specified": I thought we had decided that
+> the aspect and pragma names always match (so it's "Pack", not
+> "packing".
+
+We did decide that for existing language-defined aspects (long after this
+wording was created), but of course there is no such requirement for future
+aspects nor implementation-defined ones. It's close, but I think I'm going to
+err on the side of making less work for myself and not change it.
+
+> 13.1(8.e.1/3): I suggest this para be deleted.  It's not really
+> informative, especially if pragma names match aspect names (as they
+> should).
+
+This is explaining why we require the pragma names to match aspect names.
+Perhaps I didn't do a good job, but it seems worthwhile to mention it. The first
+sentence is certainly true and important (if we didn't have this rule, we'd have
+to give an aspect name explicitly for each pragma), and we don't want anonymous
+aspects. The second sentence doesn't say much, so I got rid of it. The third
+sentence really ought to talk about the aspecting naming for attributes.
+
+> 13.2(5): "A pragma Pack specifies the packing aspect of
+> representation; the type (or the extension part) is said to be
+> packed."
+> "A type (or extension part) with the Pack aspect specified is said to
+> be packed."
+
+This is rewritten by AI05-0229-1.
+
+> 13.3(11.1/3): This is already covered by 13.3(13/3).
+
+No it's not: this is a Legality Rule (it is illegal to take 'Address of such a
+prefix). We don't want "erroneous execution" if we can help it. Similarly, this
+raises Program_Error when it is used. (13/3 is only about specification of an
+Address, not about use.)
+
+> 13.3(13/3): "and appropriate for the entity and its use"
+> adds nothing of value.
+>
+> 13.3(13.a): Same here.
+
+Strongly disagree with this, and in any case you are directly contradicting the
+approved AI. "Valid" has a technical meaning in Ada, and it is hard to imagine
+an invalid address under that meaning. What this is really talking about is how
+the address is used, not anything about its "validity". The only way to get the
+intended meaning out of the original wording is to apply Robert's Rule, but it
+is always better to fix the wording.
+
+> 13.3.1(6/3): "} )" --> "})".
+
+I think there is an automatic space after those index entries (there is no space
+in the source); in any event, these don't appear in the RM, so they're
+irrelevant.
+
+> 13.3.1(11/3): "[ are" --> "[are".
+> "point" --> "place" (we don't normally talk about "points" in this
+> sense, I think).
+> This notion of being resolved at a place (or point) seems overly
+> implementation oriented.  Seems like we should instead say something
+> like "The visibility of defining names in an aspect_definion is is as
+> if it occured at the end...".
+
+I think we changed this wording sometime since your review; it doesn't mention
+point or place now.
+
+> 13.3.1(12/3): Two occurrences of "visible" that I think should be
+> "directly visible".
+> Not sure why "sub" is in parens in "(sub)type" (last word).
+
+I think you are right; I made all of these changes in AI05-0183-1.
+
+> 13.3.2(6/3): Doesn't fit in with 13.3.1(8/3), which is expecting us to
+> define the type of the aspect, not again define the expected type for
+> the expression.
+
+I agree, but I don't know how to define the type of the aspect to be "any
+boolean type". So I think we have to repeat this here, either that or declare
+that the aspect is Boolean and forget allowing other boolean types.
+
+Other ideas welcome.
+
+> 13.3.2(8/3): "independent of context" doesn't sound right.
+> "independently"?  Anyway, shouldn't we be talking about the "single
+> type" notion in 8.6(27/2)?
+
+It currently says "independently". "Single types" are used to put requirements
+on expected types (see 3.10.2(2/2) and 4.3.1(8/2)), but when there is an
+expected type, we have already said what happens. I'm a bit dubious that there
+is any case that needs to be resolved "independently of context", there would be
+problems with the semantics of other parts of the language if there was any
+expressions that don't have an expected type. So I think this is somebody doing
+a CYA that isn't really needed. (But I'm not willing to change it without
+additional guidance.)
+
+> 13.9.1(14.e/3):
+>
+>     `Rosen trick"
+>
+> has mismatched quotes.  Also "squirreling" --> "squirreling away"
+> Index entry for "squirrel away" should be updated.
+> I'd delete this entire para, though.
+
+Besides needing to carry the "Correction" tag to show that this is a BI (and
+thus applies to Ada 2005 compilers), this is really a language extension. It
+isn't classified as that, since the programs in question are legal but
+erroneous.
+
+> 13.11(21.h/3): "which" --> "that"
+
+OK.
+
+> 13.11(43.i/3): "specify the" --> "specify that the".
+
+OK.
+
+> 13.11(43.j/3): "an allocators" singular or plural
+
+OK.
+
+> 13.11.2(19.b/3): "It hard" --> "It is hard"
+
+OK.
+
+> 13.12.1(2/2): Index entry refers to "_Pragmas_"; should be
+> "_Attributes_".  (By the way, this is the first time I EVER recall
+> making use of those in-line index "{...}" thingies!
+> Maybe they should be removed, even from the AARM.)
+
+I do catch an indexing error occasionally by having them there, but they're much
+more likely to make it hard to read changed text. So I won't miss them (but the
+index quality will drop a bit).
+
+> 13.13.2(52/3): "]" appears at start of line.  Maybe you could fix all
+> these by doing a global search and making sure stray blanks don't
+> sneak into the @redundant command or whatever it is.
+
+Sometimes people bracket the redundant text like a change, including the spaces
+needed for that text. It would be quite a bit of work to find those, and I'm
+mainly concerned about the format of the RM (the AARM is a poor stepchild here).
+
+> 13.13.2(56.d/3): "which" --> "that"
+
+OK.
+
+> 13.14(15.e/3): One does not "go" through hoops; one "jumps"
+> through them.
+
+OK.
+
+> Whew!  That was a lot of work.
+
+Same here! But somehow you managed to not make a single change that required me
+to put anything into the Editorial Review AI. So it could have been a lot worse.
+:-)
+
+****************************************************************
+
 From: Edmond Schonberg
 Sent: Thursday, October 14, 2010  3:52 PM
 
@@ -1004,6 +2074,61 @@
 
 ****************************************************************
 
+From: John Barnes
+Sent: Tuesday, April 19, 2011  5:14 AM
+
+I am puzzled over some of the new string functions in AI-1. The Hashing ones all
+with Ada.Containers. That;s OK because the type Hash is (sadly) declared
+therein. But the string ones puzzle me.
+
+Consider
+
+The library function Strings.Equal_Case_Insensitive has the following
+declaration:
+
+function Ada.Strings.Equal_Case_Insensitive
+  (Left, Right : String) return Boolean;
+pragma Pure (Equal_Case_Insensitive);
+
+Compares strings Left and Right, converted to lower case, for equality.
+
+The library function Strings.Fixed.Equal_Case_Insensitive has the
+following declaration:
+
+with Ada.Containers, Ada.Strings.Equal_Case_Insensitive;
+function Ada.Strings.Fixed.Equal_Case_Insensitive
+   (Left, Right : String) return Boolean
+   renames Ada.Strings.Equal_Case_Insensitive;
+pragma Pure(Equal_Case_Insensitive);
+
+The generic library function Strings.Bounded.Equal_Case_Insensitive has
+the following declaration:
+
+with Ada.Containers;
+generic
+   with package Bounded is
+          new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
+function Ada.Strings.Bounded.Equal_Case_Insensitive
+  (Left, Right : Bounded.Bounded_String) return Boolean;
+pragma Preelaborate(Equal_Case_Insensitive);
+
+Equivalent to Strings.Equal_Case_Insensitive (Bounded.To_String (Key));
+
+Why does Fixed.Equal_Case_Insenstive have a with for  Ada.Containers? It's only
+a renaming of the plain one which doesn't.
+
+And what is the Bounded one to do with Key?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 28, 2011  9:50 PM
+
+Looks like sloppy cutting-and-pasting to me. But it's weird that nobody ever
+read those very closely. I put fixes into the editorial review AI.
+
+****************************************************************
+
 From: Gary Dismukes
 Sent: Saturday, October 16, 2010  1:00 AM
 
@@ -1542,6 +2667,454 @@
 Thank goodness; it's taken me parts of three days to deal with these...
 
 ****************************************************************
+
+From: Matthew Heaney
+Sent: Monday, April 11, 2011  9:31 PM
+
+I'm reading AI05-0136.  The first line of my copy says:
+
+10-06-02    AI05-0136-1/07
+
+Issue 1/3:
+
+The description of:
+
+    procedure Splice_Subtree (Container: in out Tree;
+                              Parent   : in     Cursor;
+                              Before   : in     Cursor;
+                              Position : in     Cursor);
+
+
+says:
+
+(quote)
+
+If Position equals No_Element or designates a root node, Constraint_Error is
+propagated.
+
+(end quote)
+
+I think this might be incorrect.  I think the exception behavior should match
+the description of:
+
+    procedure Splice_Subtree (Target   : in out Tree;
+                              Parent   : in     Cursor;
+                              Before   : in     Cursor;
+                              Source   : in out Tree;
+                              Position : in out Cursor);
+
+
+which states that:
+
+(quote)
+
+If Position equals No_Element, Constraint_Error is propagated. If Position does
+not designate a node in Source or designates a root node, then Program_Error is
+propagated.
+
+(end quote)
+
+The case I'm talking about is when Position designates the root node of the
+tree.  In one case you get Constraint_Error, but in another you get
+Program_Error.
+
+Everywhere else in the API, if you attempt to manipulate the root, you get PE.
+I think the case cited above that raises CE might be a bug in the spec, and PE
+should be raised.
+
+Issue 2/3:
+
+Also, the description of:
+
+    procedure Splice_Subtree (Container: in out Tree;
+                              Parent   : in     Cursor;
+                              Before   : in     Cursor;
+                              Position : in     Cursor);
+
+
+says:
+
+(quote)
+
+If Position equals Before, there is no effect.
+
+(end quote)
+
+This is true, but it's not the whole story, since if
+Next_Sibling(Position) = Before, there would be no effect either.
+
+You do make this distinction in the description of the two-container version of
+Splice_Subtree (as an AARM Ramification), so it appears that it was accidentally
+omitted from the single-container version.  (Unless the omission was
+deliberate.)
+
+Issue 3/3:
+
+The description of:
+
+    procedure Insert_Child (Container : in out Tree;
+                            Parent    : in     Cursor;
+                            Before    : in     Cursor;
+                            New_Item  : in     Element_Type;
+                            Position  :    out Cursor;
+                            Count     : in     Count_Type := 1);
+
+states that:
+
+(quote)
+
+Position designates the first newly-inserted node.
+
+(end quote)
+
+The issue here is what value does Position have when Count is 0.  I think it
+should have the value No_Element, which is what we decided in York about the
+behavior of Delete for the doubly-linked list.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, April 30, 2011  1:02 AM
+
+...
+> Issue 1/3:
+>
+> The description of:
+>
+>     procedure Splice_Subtree (Container: in out Tree;
+>                               Parent   : in     Cursor;
+>                               Before   : in     Cursor;
+>                               Position : in     Cursor);
+>
+>
+> says:
+>
+> (quote)
+>
+> If Position equals No_Element or designates a root node,
+> Constraint_Error is propagated.
+>
+> (end quote)
+>
+> I think this might be incorrect.  I think the exception behavior
+> should match the description of:
+...
+> The case I'm talking about is when Position designates the root node
+> of the tree.  In one case you get Constraint_Error, but in another you
+> get Program_Error.
+>
+> Everywhere else in the API, if you attempt to manipulate the root, you
+> get PE.  I think the case cited above that raises CE might be a bug in
+> the spec, and PE should be raised.
+
+I agree, just looks like an oversight to me.
+
+> Issue 2/3:
+>
+> Also, the description of:
+>
+>     procedure Splice_Subtree (Container: in out Tree;
+>                               Parent   : in     Cursor;
+>                               Before   : in     Cursor;
+>                               Position : in     Cursor);
+>
+>
+> says:
+>
+> (quote)
+>
+> If Position equals Before, there is no effect.
+>
+> (end quote)
+>
+> This is true, but it's not the whole story, since if
+> Next_Sibling(Position) = Before, there would be no effect either.
+
+We don't need to save that normatively; we do need to say the above normatively.
+
+> You do make this distinction in the description of the two-container
+> version of Splice_Subtree (as an AARM Ramification), so it appears
+> that it was accidentally omitted from the single-container version.
+> (Unless the omission was
+> deliberate.)
+
+I think it was deliberate; we didn't repeat the AARM notes in general (too much
+clutter), and the single container version is just a restricted version of the
+other one.
+
+We need to mention the case when Position = Before, since it isn't possible to
+insert a node before itself (and someone is sure to ask what it means if we
+don't spell it out). OTOH, we don't need to mention the other case since it
+falls out "naturally": inserting a node into the position it already has is
+harmless.
+
+Note that there is some missing wording in the Source/Target version of
+Splice_Subtree; specifically part of the Position = Before wording. So we need
+to modify this wording:
+
+"If Source denotes the same object as Target, then{: if Position equals Before
+there is no effect; if Position designates an ancestor of Parent or is equal to
+Parent, Constraint_Error is propagated; [else]{otherwise}, ..." [The last is
+from Gary's editorial review; the colon is needed to avoid ambiguity in the
+following.]
+
+> Issue 3/3:
+>
+> The description of:
+>
+>     procedure Insert_Child (Container : in out Tree;
+>                             Parent    : in     Cursor;
+>                             Before    : in     Cursor;
+>                             New_Item  : in     Element_Type;
+>                             Position  :    out Cursor;
+>                             Count     : in     Count_Type := 1);
+>
+> states that:
+>
+> (quote)
+>
+> Position designates the first newly-inserted node.
+>
+> (end quote)
+>
+> The issue here is what value does Position have when Count is 0.  I
+> think it should have the value No_Element, which is what we decided in
+> York about the behavior of Delete for the doubly-linked list.
+
+I don't see what Delete has to do with anything; it always sets the Position to
+No_Element (the Count is irrelevant).
+
+And there is no answer to this question in the linked list Inserts that have out
+Position parameters, either (the wording for these Tree routines was lifted
+directly from the linked list wording). (There is an answer for the vector, at
+least, and neither Maps nor Sets have these Count parameters.)
+
+My preference for the semantics of this is to raise Constraint_Error. It doesn't
+make sense to ask to insert no elements and at the same time expect to get a
+cursor back of the inserted element. (As you would say, any other result would
+violate the postcondition of the routine that Position points at the first
+inserted element - that seems bad.)
+
+(I'm surprised that any of these Count parameters allow zero, but it is too late
+to change that.)
+
+So I added "; if Count is zero, Constraint_Error is propagated." to each of
+these. (We could also define a Positive_Count_Type subtype, but that seems to be
+overkill for this very isolated case, and it would be [slightly] incompatible
+for the existing List routines.)
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Tuesday, April 12, 2011  9:42 PM
+
+I see that Iterate_Children (and also Reverse_Iterate_Children) is declared this
+way:
+
+    procedure Iterate_Children
+      (Container : in Tree;
+       Parent    : in Cursor;
+       Process   : not null access procedure (Position : in Cursor));
+
+The Container parameter does not seem to serve any obvious purpose.
+Is the Container parameter there by mistake?  Is this is a bug in the spec?
+
+It seems odd that Iterate_Subtree does not accept a Container parameter, yet
+Iterate_Chlidren does.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 29, 2011  1:51 AM
+
+I suppose it is a mistake, probably the regular Iterate was copied to create
+this one. (I think this was added fairly late during the design.) I've removed
+it and the associated wording.
+
+Humm, Find_in_Subtree and Ancestor_Find seem to have the same problem. (Your
+question about Ancestor_Find couldn't have happened if that routine didn't have
+a Container parameter.)
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Friday, April 29, 2011  1:22 PM
+
+Right, I meant to post about those too, but wasn't sure this was the proper
+forum (I can use Ada-Comment if you prefer).
+
+So did the wording in the AI for Iterate_Children, Find_In_Subtree,
+Ancestor_Find, etc, get changed, to remove the Container parameter?
+
+BTW, Is this the link for the document I should work from:
+
+http://ada-auth.org/standards/ada12.html
+
+instead of using the AI itself?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 29, 2011  1:42 PM
+
+> Right, I meant to post about those too, but wasn't sure this was the
+> proper forum (I can use Ada-Comment if you prefer).
+
+Either is fine.
+
+> So did the wording in the AI for Iterate_Children, Find_In_Subtree,
+> Ancestor_Find, etc, get changed, to remove the Container parameter?
+
+Yes. (Pending ARG approval, of course, but I'd be surprised if anyone
+objects.)
+
+> BTW, Is this the link for the document I should work from:
+>
+> http://ada-auth.org/standards/ada12.html
+>
+> instead of using the AI itself?
+
+Yes, this is the most recent state of the Standard. Note that it would best to
+work from Draft 12, but it isn't available yet (I've still got 20 AIs to add to
+it). If an AI isn't in the Standard, then you should look at it, but I believe
+that all of the old containers AIs are in Draft 11 (some corrections are new,
+those are in AI05-0248-1 if you need to see them).
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, April 13, 2011  2:17 PM
+
+The description of
+
+    function Ancestor_Find (Container : Tree;
+                            Item      : Element_Type;
+                            Position  : Cursor)
+       return Cursor;
+
+says:
+
+(quote)
+
+If Position equals No_Element, then Constraint_Error is propagated; if Position
+does not designate an element in Container (including if it designates the root
+node), then Program_Error is propagated.
+
+(end quote)
+
+
+That parenthetical bit about raising Program_Error if Position designates the
+root node seems wrong.  Shouldn't the function return No_Element in that case?
+
+We search for Item starting from the Position, up to each successive ancestor
+node, stopping when we reach the root node.  If we reach the root node, then the
+search terminates by returning No_Element.
+
+But if Position happens to have the root node as its initial value, then this is
+just the limiting case of the search.  Raising PE seems wrong in this case.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 29, 2011  1:37 AM
+
+I wouldn't call it "wrong", but unnecessary would probably be true. The intent
+was that we raise Program_Error if we pass a cursor that designates the root
+node if we are going to operate on the contained element. This routine is a bit
+weird that way; I suspect that I assumed that there had to be at least one
+element searched. But as you point out, that doesn't seem necessary.
+
+So I changed the first sentence (but *not* in AI05-0136-1, that's closed; it's
+done in AI05-0248-1) to the other normal wording: "If Position equals
+No_Element, then Constraint_Error is propagated; if Position does not designate
+a node in Container, then Program_Error is propagated." I also changed the
+starting point from "element" to "node" (since there might not be an element).
+
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, April 18, 2011  6:29 PM
+
+> AI05-0248-1 Propose a rewording of the Assign routines for the
+> containers (there are 6) that does not use "Corresponding Elements".
+> (This probably will be placed in a new AI.)
+
+Here's another attempt,
+   -- Steve
+
+
+!wording
+
+In A.18.2(147.2/3) [describing Vector procedure Assign], replace
+
+   Each element of Source is assigned to the corresponding element
+   of Target.
+
+with
+
+   The elements of Source are then copied to Target as for an
+   assignment_statement assigning Source to Target (this includes
+   setting Target's length to be that of Source).
+
+====
+
+In A.18.3(86.2/3 [describing Doubly_Linked_Lists procedure Assign], replace
+
+    Otherwise, it clears Target, and each element of Source is assigned
+    to the corresponding element of Target.
+
+with
+
+    Otherwise, the elements of Source are copied to Target as for an
+    assignment_statement assigning Source to Target.
+
+====
+
+In A.18.4(41.2/3) [describing Maps procedure Assign], replace
+
+    Otherwise, each key/element pair of Source is assigned to the
+    corresponding key/element pair of Target.
+
+with
+
+    Otherwise, the key/element pairs of Source are copied to Target as
+    for an assignment_statement assigning Source to Target.
+
+====
+
+In A.18.7(36.2/3) [describing Sets procedure Assign], replace
+
+    Otherwise, each element of Source is assigned to the
+    corresponding element of Target.
+
+with
+
+    Otherwise, the elements of Source are copied to Target as
+    for an assignment_statement assigning Source to Target.
+
+====
+
+In A.18.10(111/3) [describing Multiway_Trees procedure Assign], replace
+
+    Otherwise, it calls Clear (Target), and then each element of Source
+    is assigned to a corresponding element in Target.
+
+with
+
+    Otherwise, the elements of Source are copied to Target as
+    for an assignment_statement assigning Source to Target.
+
+
+====
+
+Note: the existing wording for the Honey_Pot generic (A.18.18) needs no changes.
+
+Question: In the vector case, do we want the parenthetical "this includes ..."
+verbiage? It didn't seem necessary to add analogous text in the other cases.
+
+****************************************************************
+
 
 From: Jean-Pierre Rosen
 Sent: Tuesday, September 21, 2010  5:07 AM

Questions? Ask the ACAA Technical Agent