!standard 11.4.1(10.1/2) 11-05-02 AI05-0248-1/04 !standard A.1(35) !standard A.4.10(0) !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(86/2) !standard A.18.3(88/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) !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 !status received 10-09-16 !priority Medium !difficulty Easy !subject More Rewordings from the First Editorial Review !summary Change wording of existing approved AIs as suggested by various ARG members during the first editorial review of the draft standard. !question Some of the new wording in the standard is unnecessarily confusing. Should we improve it? (Yes.) !recommendation (See Summary.) !wording [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 (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(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." 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 <> 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.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: "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; ..." 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): "... 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." 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, 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 with an @I@fa and a @I@fa, the message is the @i@fa. For the occurrence raised by a @fa with an @i@fa but without a @i@fa, 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 with an @I@fa and a @I@fa, the message is the @i@fa. For the occurrence raised by a @fa with an @i@fa but without a @i@fa, 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 @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>, '@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 @xcode<@b Compose (Containing_Directory : @b String := ""; Name : @b String; Extension : @b String := "") @b String;> @dinss @xcode<@b Name_Case_Kind @b (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);> @xcode<@b Name_Case_Equivalence (Name : @b String) @b Name_Case_Kind;> !corrigendum A.16(82/2) @dinsa @xindent @dinss @xcode<@b Name_Case_Equivalence (Name : @b String) @b Name_Case_Kind;> @xindent !corrigendum A.16.1(0) @dinsc Force a conflict; real text found in the conflict file. !corrigendum A.17(8/2) @drepl @xcode< @b Iterate ( Process : @b (Name, Value : @b String));> @dby @xcode< @b Iterate (Process : @b (Name, Value : @b String));> !corrigendum A.17(22/2) @drepl @xcode<@b Iterate ( Process : @b (Name, Value : @b String));> @dby @xcode<@b Iterate (Process : @b (Name, Value : @b String));> !corrigendum A.18.2(147/2) @dinsa @xindent @dinss @xcode<@b Assign (Target : @b Vector; Source : @b Vector);> @xindent assigning Source to Target (this includes setting Target's length to be that of Source).> !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(86/2) @dinsa @xindent shall be unconstrained.> @dinss @xcode<@b Assign (Target : @b List; Source : @b List);> @xindent assigning Source to Target.> @xcode<@b Copy (Source : List) @b List;> @xindent !corrigendum A.18.3(88/2) @drepl @xindent @dby @xindent !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(41/2) @dinsa @xindent shall be unconstrained.> @dinst @xcode<@b Assign (Target : @b Map; Source : @b Map);> @xindent !corrigendum A.18.4(43/2) @drepl @xindent @dby @xindent !corrigendum A.18.4(75/2) @dinsa @xindent 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 tampers with the cursors of Container. Any exception raised by Process.@b is propagated.> @dinss @s8<@i>@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 Assign (Target : @b Map; Source : @b Map);> @xindent !corrigendum A.18.7(36/2) @dinsa @xindent with the element designated by Position as the argument. Program_Error is propagated if Process.@b tampers with the elements of Container. Any exception raised by Process.@b is propagated.> @dinss @xcode<@b Assign (Target : @b Set; Source : @b Set);> @xindent assigning Source to Target.> !corrigendum A.18.7(38/2) @drepl @xindent @dby @xindent !corrigendum A.18.7(96/2) @dinsa If Element_Type is unconstrained and definite, then the actual Element parameter of Process.@b shall be unconstrained. @dinss @s8<@i>@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 Assign (Target : @b Set; Source : @b Set);> @xindent !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**2) or better, and the average time complexity should be better than O(@i**2), where @i 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) @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 tests. !appendix [Editor's note: These mails are organized by section of change, rather than by the date.] From: John Barnes Sent: Tuesday, September 21, 2010 1:41 PM I found a few typos in my review. I also added a note about 4.9(37.a/3) which seems to be out of place. So here it is again attached as a text file since I noticed that copying it into the email produced lots of white space. ==== Review of RM 2012 Introduction 57.13/3 I expect that I have to write this. 1.1.4 (12/3) this has "a iterator specification" rather than "an iterator specification" Maybe old version of AI got in somehow. In any event, further to recent email discussion, I assume this will all stay as it originally was. 1.1.4 (21.d3) Reads as if punctuation is wrong. In any event this should go with changes to use => in quantified expressions. 2.2(7.1/3) Should say "One or more". It's OK in the AI. 2.3(8.d/3) rem{o}ved and why the original Ada 2005. Surely there is only one. Delete original. 2.9(3.f/2) this should be 3.f/3 and in red. Also please edit as below 3.f/2 {AI05-0176-1} {incompatibilities with Ada 2005} The following word 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 changed, but we do not expect them to be common. 4.5.2(39.m/3) line 3 change "made" to "make" 4.5.5(35.e/3) line 3 change "made" to "make" (cut and paste error?) 4.5.7(5.l/3) discussion about compilers might usefully point out that conditional expressions don't have end if and end case which might impact on error recovery. Also edit as below, change a to an 5.l/3 Implementation Note: {AI05-0147-1} Implementers are cautioned to consider error detection when implementing the syntax for conditional_expressions. An if_expression and a{n} if_statement are very similar syntactically, (as are a case_expression and a case_statement) and simple mistakes can appear to change one into the other, potentially causing errors to be moved far away from their actual location. 4.5.7(12.a/3) edit as below, add s to expression 12.a/3 Ramification: If the type of the conditional_expression cannot be determined by one of these rules, the Name Resolution has failed for that expression, even if the dependent_expression{s} would resolve individually. 4.5.7(16/3) edit as below, insert "the" on line 6 the AI needs changing too. 16/3 {AI05-0147-1} For the execution of an if_expression, the condition specified after if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif True then), until one evaluates to True or all conditions are evaluated and yield False. If a condition evaluates to True, the associated dependent_expression is evaluated, converted to the type of the if_expression, and {the} resulting value is the value of the if_expression. Otherwise, the value of the if_expression is True. 4.5.9 Change this to use => rather than vertical bar. This simplifies things a bit. Also we seem to be running ahead of ourselves. We don't have iterator specification defined yet. 1/3 {AI05-0176-1} quantified_expression ::= for quantifier loop_parameter_specification [|]{=>} predicate | for quantifier iterator_specification [|]{=>} predicate delete (3.a/3) comment about the vertical bar can go change examples 11/3 and 13/3 to use => 4.8(2.a/3) I would delete "the most" as below 2.a/3 Reason: Such an uninitialized allocator would necessarily raise Constraint_Error, as the default value is null. Also note that the syntax does not allow a null_exclusion in an initialized allocator, so it makes [the most] sense to make the uninitialized case illegal as well. 4.8(5.3/3) seems to disagree with AI-157. too many sentences deleted also why was last sentence of 5.e/3 deleted? 4.9(33 etc) I don't see why we really need all this statically unevaluated stuff (nasty term). We don't get exceptions at compile time. I don't believe we discussed this much in a meeting. If we did I was asleep. And I don't think the AI has been reviewed yet. On second thoughts it's OK. 4.9(37.a/3) This seems to be partly in the wrong place. Consider 36/3 * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of an if_expression where the condition corresponding to at least one preceding dependent_expression of the if_expression is static and equals True; or 36.a/3 Reason: We need this bullet so that only a single dependent_expression is evaluated in a static if_expression if there is more than one condition that evaluates to True. The part about conditions makes 36.b/3 (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min) 36.c/3 legal if N and Min are static and N = 0. 37/3 * {AI05-0188-1} a dependent_expression of a case_expression whose expression is static and not covered by the corresponding discrete_choice_list. 37.a/3 Discussion: {AI05-0147-1} {AI05-0188-1} We need the "of the if_expression" here so there is no confusion for nested if_expressions; this rule only applies to the conditions and dependent_expressions of a single if_expression. Similar reasoning applies to the "of a case_expression" of the last bullet. This says "of the if expression" and so seems to be referring to 36/3 not 37/3. == Annex G looks fine. All corrections have been made OK. There were no real changes thank goodness. **************************************************************** From: Randy Brukardt Sent: Thursday, March 31, 2011 11:46 PM John Barnes wrote in his editorial review way back in September: >Review of RM 2012 > >Introduction 57.13/3 I expect that I have to write this. You did. :-) >1.1.4 (12/3) this has "a iterator specification" rather than "an iterator specification" > >Maybe old version of AI got in somehow. > >In any event, further to recent email discussion, I assume this will >all stay as it originally was. > >1.1.4 (21.d3) Reads as if punctuation is wrong. In any event this >should go with changes to use => in quantified expressions. All of this 1.1.4 stuff is OBE. > 2.2(7.1/3) Should say "One or more". It's OK in the AI. Must have keyed this one by hand. Fixed. > 2.3(8.d/3) rem{o}ved and why the original Ada 2005. Surely there is only > one. Delete original. This is documenting a "correction" (a Binding Interpretation) which applies to Ada 2005 compilers as well as Ada 2012. In theory, all Ada compilers will make the change. (So far as I know, no compiler ever was released implementing the original rule, so the incompatibility is not very likely :-). 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 by Amendment 1"? But I want some indication that we're talking about the original, unsullied version of Ada 2005. I don't think writing out the entire explanation is helpful (because this is common): "... This change can only affect programs written for an early Ada 2005 implementation (recall that as a correction, Ada 2005 compilers can and ought to apply this change), so there should be few such programs. " 1.1.2(39.dd/3) explains the meaning of "Correction:"; it too uses "original Ada 2005 definition". There are similar paragraphs for the other "from Ada 2005" sections as well. If you have a suggestion for a better presentation, I'll be happy to apply it. >2.9(3.f/2) this should be 3.f/3 and in red. Also please edit as below >3.f/2 {AI05-0176-1} {incompatibilities with Ada 2005} The following word > 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 changed, but we do not > expect them to be common. OK, although 2 out of 3 already were detected. > 4.5.2(39.m/3) line 3 change "made" to "make" > 4.5.5(35.e/3) line 3 change "made" to "make" (cut and paste error?) Obviously, I saved time when inserting errors by cutting and pasting them. :-) Fixed. > 4.5.7(5.l/3) discussion about compilers might usefully point out that > conditional expressions > don't have end if and end case which might impact on error recovery. > Also edit as below, change a to an > >5.l/3 Implementation Note: {AI05-0147-1} Implementers are cautioned to > consider error detection when implementing the syntax for > conditional_expressions. An if_expression and a{n} if_statement are > very similar syntactically, (as are a case_expression and a > case_statement) and simple mistakes can appear to change one into > the other, potentially causing errors to be moved far away from > their actual location. This was already done (including adding an extra sentence), probably in response to your editorial review of the AI. >4.5.7(12.a/3) edit as below, add s to expression > >12.a/3 Ramification: If the type of the conditional_expression cannot be > determined by one of these rules, the Name Resolution has failed for > that expression, even if the dependent_expression{s} would resolve > individually. OK. > 4.5.7(16/3) edit as below, insert "the" on line 6 the AI needs > changing too. > > 16/3 {AI05-0147-1} For the execution of an if_expression, the > condition specified after if, and any conditions specified after > elsif, are evaluated in > succession (treating a final else as elsif True then), until one evaluates to > True or all conditions are evaluated and yield False. If a condition evaluates > to True, the associated dependent_expression is evaluated, converted to the > type of the if_expression, and {the} resulting value is the value of > the if_expression. Otherwise, the value of the if_expression is True. Previously fixed. > 4.5.9 Change this to use => rather than vertical bar. This simplifies > things a bit. > > Also we seem to be running ahead of ourselves. We don't have iterator > specification defined yet. > > 1/3 {AI05-0176-1} quantified_expression ::= for quantifier > loop_parameter_specification [|]{=>} predicate > | for quantifier iterator_specification [|]{=>} predicate > >delete (3.a/3) comment about the vertical bar can go >change examples 11/3 and 13/3 to use => This was done as part of an AI update long ago. > 4.8(2.a/3) I would delete "the most" as below > >2.a/3 Reason: Such an uninitialized allocator would necessarily raise > Constraint_Error, as the default value is null. Also note that the > syntax does not allow a null_exclusion in an initialized allocator, > so it makes [the most] sense to make the uninitialized case illegal as > well. OK. >4.8(5.3/3) seems to disagree with AI-157. too many sentences deleted There are two AIs reflected in this paragraph, AI05-0052-1 and AI05-0157-1. AI05-0157-1 deletes the last sentence. AI05-0052 moves the penultimate sentence to its own paragraph (4.8(5.5/3)). So I think this is correct. >also why was last sentence of 5.e/3 deleted? It was 4.8(5.e/2); it was replaced by this longer explanation from AI05-0157-1. Typically, deleted text goes after the inserted text that replaces it. I do realize it looks weird, but I don't think that there is much that can be done. >4.9(33 etc) I don't see why we really need all this statically >unevaluated stuff (nasty term). We don't get exceptions at compile >time. I don't believe >we discussed this much in a meeting. If we did I was asleep. And I don't think >the AI has been reviewed yet. On second thoughts it's OK. Nice to know that you have strong convictions. :-) The term is new, of course, but the concept exists all the way back to Ada 95. The right-hand side of a short circuit is not evaluated at compile-time if the left operand determines the value. The important part of that is that a static expression is illegal if it fails a compile-time check. If we didn't have "statically unevaluated", "A /= 0 and then 100 / A > 10" would be illegal if A is statically 0. Which would defeat the purpose of having written the short-circuit in the first place. The term is needed to extend this idea to conditional expressions. We don't want (if A /= 0 then 100 / A else 0) to be illegal if A is statically 0 - this would defeat the purpose of the conditional itself. Nobody was all that excited about this term, but it was the best we came up with. If you can come up with a better term, please do! >4.9(37.a/3) > >This seems to be partly in the wrong place. Consider > >36/3 * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of > an if_expression where the condition corresponding to at least one > preceding dependent_expression of the if_expression is static and equals > True; or > >36.a/3 Reason: We need this bullet so that only a single > dependent_expression is evaluated in a static if_expression > if there is more > than one condition that evaluates to True. The part about > conditions makes > >36.b/3 (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min) > >36.c/3 legal if N and Min are static and N = 0. > >37/3 * {AI05-0188-1} a dependent_expression of a case_expression whose > expression is static and not covered by the corresponding > discrete_choice_list. > >37.a/3 Discussion: {AI05-0147-1} {AI05-0188-1} We need the "of the > if_expression" here so there is no confusion for nested > if_expressions; this rule only applies to the conditions and > dependent_expressions of a single if_expression. Similar reasoning > applies to the "of a case_expression" of the last bullet. > >This says "of the if expression" and so seems to be referring to 36/3 >not 37/3. Yup. It was already moved. >== > >Annex G looks fine. All corrections have been made OK. There were no >real changes thank goodness. Great. I think this is the point where you announce that you need a gin. I feel the same way, although in my case it will be a Capital Blonde Dopplebock (just picked that up shopping on Tuesday - it's probably Capital's best beer, although rather expensive). **************************************************************** From: Bob Duff Sent: Friday, April 1, 2011 7:47 AM > >Review of RM 2012 Question for John: Did you actually read the entire document? 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 > alternative wording. "Initial Ada 2005"? "Uncorrected Ada 2005"? "Unmodified Ada 2005"? > "2007 version of the Ada 2005"? ;-) "Ada 2005 as defined by directly > by Amendment 1"? "original Ada 2005" expresses perfectly what you mean. > >3.f/2 {AI05-0176-1} {incompatibilities with Ada 2005} The following word > > 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 changed, but we do not > > expect them to be common. There are some some in the AdaCore test suite. **************************************************************** From: John Barnes Sent: Friday, April 1, 2011 11:58 AM > Question for John: Did you actually read the entire document? > Did you print it out, or read it online? > How long did it take? 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 cases where more than one AI affected a paragraph. **************************************************************** From: Randy Brukardt Sent: Friday, April 1, 2011 11:19 PM > > >3.f/2 {AI05-0176-1} {incompatibilities with Ada 2005} > > > The following word > > > 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 > > > 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. 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. :-) :-) **************************************************************** 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 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: 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 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: 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.) [Editor's Note: Later discussion cast doubt on this solution; it has been put into a separate AI.] **************************************************************** 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 > 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. ****************************************************************