!standard x.xx(xx/x) 11-03-31 AI05-0248-1/01 !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 !discussion These wording changes seem to be an improvement in readability and understandability, but are not intended to change the meaning of the words. !corrigendum xx.xx(xx/x) !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. :-) :-) ****************************************************************