--- ai05s/ai05-0158-1.txt 2010/11/13 01:26:26 1.9 +++ ai05s/ai05-0158-1.txt 2010/11/13 02:18:40 1.10 @@ -1,4 +1,4 @@ -!standard 3.8.1(5) 10-10-21 AI05-0158-1/05 +!standard 3.8.1(5) 10-11-12 AI05-0158-1/06 !standard 4.4(3) !standard 4.5.2(3) !standard 4.5.2(4) @@ -6,6 +6,8 @@ !standard 4.5.2(28) !standard 4.9(11) !class Amendment 09-06-07 +!status Amendment 2012 10-11-12 +!status ARG Approved 9-0-1 10-10-29 !status work item 09-06-07 !status received 09-03-30 !priority Low @@ -14,47 +16,47 @@ !summary -Extend the syntax of membership tests to simplify complex conditions that can -be expressed as membership in a subset of values of any type. Introduce syntax -for a list of expressions that may be used in loop contexts as well. +Extend the syntax of membership tests to simplify complex conditions that can +be expressed as membership in a subset of values of any type. Introduce syntax +for a list of expressions that may be used in loop contexts as well. !problem -Conditions of the form (X = A) or else (X = B) or else (X = C) where A, B, C -are of some arbitrary type are common, and will be more frequent when -pre- and post-conditions become widely used. If the values of A, B,and C are -contiguous values of some discrete type, the expression can be -written as a membership operation: (X in A..C) . Otherwise this syntactic -shortcut is not available. We propose a simple extension of the syntax of -membership operations, so that the right operand can specify a subset of values -of some type. The type does not need to be discrete, and the choices do not -need to be static, so that one can write: - -if C not in 'A' | 'B' | 'O' then Put_Line ("invalid blood type"); else .. - -while Name (1 .. N) in T.Element (X) | T.Element (Y) | T.Element (Z) loop ... +Conditions of the form (X = A) or else (X = B) or else (X = C) where A, B, C +are of some arbitrary type are common, and will be more frequent when +pre- and post-conditions become widely used. If the values of A, B,and C are +contiguous values of some discrete type, the expression can be +written as a membership operation: (X in A..C) . Otherwise this syntactic +shortcut is not available. We propose a simple extension of the syntax of +membership operations, so that the right operand can specify a subset of values +of some type. The type does not need to be discrete, and the choices do not +need to be static, so that one can write: + +if C not in 'A' | 'B' | 'O' then Put_Line ("invalid blood type"); else .. + +while Name (1 .. N) in T.Element (X) | T.Element (Y) | T.Element (Z) loop ... !proposal We propose a simple extension of the syntax of membership operations, so that the right operand can specify a subset of values -of some type. We propose a simple extension of the syntax of -membership operations, so that the right operand can specify a subset of values -of some type. The type does not need to be discrete, and the choices do not -need to be static, so that one can write: - -if C not in 'A' | 'B' | 'O' then Put_Line ("invalid blood type"); else .. - -while Name (1 .. N) in T.Element (X) | T.Element (Y) | T.Element (Z) loop ... +of some type. We propose a simple extension of the syntax of +membership operations, so that the right operand can specify a subset of values +of some type. The type does not need to be discrete, and the choices do not +need to be static, so that one can write: + +if C not in 'A' | 'B' | 'O' then Put_Line ("invalid blood type"); else .. + +while Name (1 .. N) in T.Element (X) | T.Element (Y) | T.Element (Z) loop ... !wording -Replace 3.8.1 (5): - - discrete_Choice ::= choice_expression | discrete_Range | others - -Replace 4.4(3): - +Replace 3.8.1 (5): + + discrete_Choice ::= choice_expression | discrete_Range | others + +Replace 4.4(3): + relation ::= simple_expression [relational_operator simple_expression] | simple_expression [not] in membership_choice_list @@ -73,14 +75,12 @@ with - The tested type of a membership test shall be determined - as follows: + The tested type of a membership test is determined as follows: - If all elements of the membership choice list have the same - type, then the tested type of the membership test is that type. - If the type of an element of the membership choice list is - elementary, then the tested type of the membership test shall - be covered by that type. + All elements of a membership choice list shall resolve to the same + type, which is the tested type; or each element shall be of an + elementary type, and the tested type shall be covered by by each of + these elementary types. If the tested type is tagged, then the simple_expression shall resolve to be of a type that is convertible (see 4.6) to the tested @@ -95,30 +95,30 @@ the tested type of the membership test is limited, then the tested type of the membership test shall have a visible primitive equality operator. + +Modify 4.5.2(27) as follows: -Modify 4.5.2(27) as follows: - -If the choice_list has a single choice, the simple expression and the choice +If the choice_list has a single choice, the simple expression and the choice are elaborated in arbitrary order. - -If the choice_list has more that one choice, the left operand is elaborated -first and the operation is equivalent to a short-circuit sequence of -individual tests on each choice. - -Modify 4.5.2 (28) as follows: - -A membership test using in yields the result True if any of the individual -tests on the elements of the choice list yields True. - -An individual membership test yields the result True if: - -* The choice is an expression, and the simple_expression is equal to the value - of the choice. If the type of the expression is a record type or a limited - type, the test uses the primitive equality for the type; otherwise the test - uses predefined equality. - -* The choice is a range or subtype mark and: - + +If the choice_list has more that one choice, the left operand is elaborated +first and the operation is equivalent to a short-circuit sequence of +individual tests on each choice. + +Modify 4.5.2 (28) as follows: + +A membership test using in yields the result True if any of the individual +tests on the elements of the choice list yields True. + +An individual membership test yields the result True if: + +* The choice is an expression, and the simple_expression is equal to the value + of the choice. If the type of the expression is a record type or a limited + type, the test uses the primitive equality for the type; otherwise the test + uses predefined equality. + +* The choice is a range or subtype mark and: + (followed by para. 29-30) Replace 4.9(11) [definition of a static expression] @@ -146,27 +146,27 @@ !discussion -The new syntax creates an upward incompatibility: a choice cannot be an -expression, as in Ada2005, but is limited to an expression without a -membership operator. This is likely to be harmless, and seems to be preferable -to making the grammar ambiguous, as shown in the following example, in which -a choice list can contain an arbitrary expression: - - X : Boolean := .. - case X is - when Y in 1..10 | 20 => -- ambiguous: - -- could be (Y in 1..10) | 20 - -- which is otherwise type-incorrect - - -Even though this is a contrived example, unlikely to show up in realistic -code, it seems preferable to modify the grammar as shown above. - -There was a suggestion that the type of an expression in a choice should be -non-limited. However, given that currently a subtype_mark in a choice can be -of any type, it would be awkward to introduce this restriction. Clearly if -the type has no primitive equality a membership test over a list of expressions -is illegal. +The new syntax creates an upward incompatibility: a choice cannot be an +expression, as in Ada2005, but is limited to an expression without a +membership operator. This is likely to be harmless, and seems to be preferable +to making the grammar ambiguous, as shown in the following example, in which +a choice list can contain an arbitrary expression: + + X : Boolean := .. + case X is + when Y in 1..10 | 20 => -- ambiguous: + -- could be (Y in 1..10) | 20 + -- which is otherwise type-incorrect + + +Even though this is a contrived example, unlikely to show up in realistic +code, it seems preferable to modify the grammar as shown above. + +There was a suggestion that the type of an expression in a choice should be +non-limited. However, given that currently a subtype_mark in a choice can be +of any type, it would be awkward to introduce this restriction. Clearly if +the type has no primitive equality a membership test over a list of expressions +is illegal. We define choices to be "statically unevaluated" so that X in Y|Z is @@ -665,7 +665,8 @@ Here is an updated version of AI05-0158 (membership tests) incorporating the changes suggested by you and Robert. -The new syntax is unambiguous, and presents a minuscule incompatibility with Ada2005. +The new syntax is unambiguous, and presents a minuscule incompatibility with +Ada2005. [Editor's note: This is version /02 of the AI.] @@ -760,7 +761,9 @@ Following the wording proposed earlier for conditional expressions, we could replace the above with: -If the membership_choice_list in a membership operation has more than one choice, then the tested type of the membership operation shall be determined by the types of the choices as follows: +If the membership_choice_list in a membership operation has more than one +choice, then the tested type of the membership operation shall be determined by +the types of the choices as follows: o if all choices have the same type, then that type is the tested type of the membership operation; o otherwise, if at least one choice has a @@ -825,9 +828,15 @@ Agreed that such cases should certainly be allowed. -This seems closely analogous with membership tests with ranges (F in 10 .. X), so it seems like we should be able to use similar resolution rules for these new guys. However, after looking at the rules, I'm scratching my head about how the existing wordi ng works for such membership tests. The rules are based on the "type of the range", but it's unclear how that gets determined in "mixed-type" cases like the above. (Relevant paragraphs are 4.5.2(3/2) and 3.5(4-5).) +This seems closely analogous with membership tests with ranges (F in 10 .. X), +so it seems like we should be able to use similar resolution rules for these new +guys. However, after looking at the rules, I'm scratching my head about how the +existing wording works for such membership tests. The rules are based on the +"type of the range", but it's unclear how that gets determined in "mixed-type" +cases like the above. (Relevant paragraphs are 4.5.2(3/2) and 3.5(4-5).) -BTW, I discussed this with Steve, and it's similarly unclear to him, but maybe someone else can shed some light. +BTW, I discussed this with Steve, and it's similarly unclear to him, but maybe +someone else can shed some light. > Following the wording proposed earlier for conditional expressions, we > could replace the above with: @@ -1567,18 +1576,19 @@ From: Bob Duff Date: Friday, October 8, 2010 11:59 AM -According to the Valencia minutes, you two are supposed to write up some resolution rules for the new "X in A | B | C..D" syntax. -(I don't think it's nearly as big of a deal as some of the emails indicate! But it's not trivial, +According to the Valencia minutes, you two are supposed to write up some +resolution rules for the new "X in A | B | C..D" syntax. (I don't think it's +nearly as big of a deal as some of the emails indicate! But it's not trivial, either.) -Anyway, can you guys please deal with the following minor questions while you're at it? I noticed these while working on -AI-153 (subtype predicates). +Anyway, can you guys please deal with the following minor questions while you're +at it? I noticed these while working on AI-153 (subtype predicates). It seems like we need a rule saying if/when these things are static expressions. Why did somebody change the syntax from: -2 expression ::= +2 expression ::= relation {and relation} | relation {and then relation} | relation {or relation} | relation {or else relation} | relation {xor relation} @@ -1589,7 +1599,8 @@ ? -The RM syntax says "and" and "or" can't be mixed, (without explicit parens) and I'm pretty sure we want to retain that rule! +The RM syntax says "and" and "or" can't be mixed, (without explicit parens) and +I'm pretty sure we want to retain that rule! Also this one: @@ -1602,7 +1613,8 @@ From: Bob Duff Date: Friday, October 8, 2010 12:03 PM -Oh, and by the way, note that for "X in Y", Y can be a subtype (as in Ada 83), or it can be a value. +Oh, and by the way, note that for "X in Y", Y can be a subtype (as in Ada 83), +or it can be a value. type Y is range 1..10; if X in Y ... @@ -1785,11 +1797,13 @@ discrete_choice ::= choice_expression | discrete_range | others -, but that's wrong. It remains (and should remain, since we don't want to introduce any more incompatibilities than necessary) +, but that's wrong. It remains (and should remain, since we don't want to +introduce any more incompatibilities than necessary) discrete_choice ::= expression | discrete_range | others -Back to the drawing board for the syntax rules, although suggested solutions are always welcome. +Back to the drawing board for the syntax rules, although suggested solutions are +always welcome. Perhaps just a stated-in-English non-BNF syntax rule something like If a discrete_choice includes a membership test, then it @@ -1816,14 +1830,14 @@ >> when A in B | C => >> syntactic ambiguity by requiring that a >> choice expression must be a simple expression. -> +> > No, it doesn't. -> +> > In my head, I had -> +> > discrete_choice ::= choice_expression | discrete_range | others -> -> , but that's wrong. +> +> , but that's wrong. Don't listen to Steve #2 when he says that Steve #1 was confused. I, Steve #3, will point out that the unmodified portion of the AI says @@ -1831,22 +1845,28 @@ Modify 3.8.1 (5) as follows: discrete_Choice ::= choice_expression | discrete_Range | others -I think this may mean that Steve #1's original proposal earlier today was ok, but at this point I'm not sure about anything. +I think this may mean that Steve #1's original proposal earlier today was ok, +but at this point I'm not sure about anything. **************************************************************** From: Randy Brukardt Date: Friday, November 12, 2010 7:14 PM -Steve #2 was correct: Steve #1's proposal did indeed reintroduce the incompatibility, because it changed the meaning of "choice_expression" from an expression subtracting membership operations to a pure simple expression. +Steve #2 was correct: Steve #1's proposal did indeed reintroduce the +incompatibility, because it changed the meaning of "choice_expression" from an +expression subtracting membership operations to a pure simple expression. That would introduce an incompatibility for modular types: when WS_BORDER or WS_SIZABLE => ... -would now require parens, whereas that would not be the case in Ada 95 or Ada 2005. +would now require parens, whereas that would not be the case in Ada 95 or Ada +2005. -That was the point behind the entire original grammar change; it just was badly botched by oversimplification. +That was the point behind the entire original grammar change; it just was badly +botched by oversimplification. -Either an English language rule should be introduced to fix the grammar change, or the grammar should simply use the original productions: +Either an English language rule should be introduced to fix the grammar change, +or the grammar should simply use the original productions: expression := relation {and relation} @@ -1864,24 +1884,30 @@ choice_relation ::= simple_expression [relational_operator simple_expression] - relation ::= + relation ::= simple_expression [relational_operator simple_expression] | simple_expression [not] in membership_choice_list membership_choice_list ::= membership_choice {'|' membership_choice} membership_choice ::= choice_expression | range | subtype_mark -[Note that there is another error in the original rules, relation is missing the relational operator case.] I don't see any advantage to the botched simplification, so I'd recommend that we use these. +[Note that there is another error in the original rules, relation is missing the +relational operator case.] I don't see any advantage to the botched +simplification, so I'd recommend that we use these. I don't think anything in Bob Duff's AI05-0153-3 changes anything here. (Although it does also change the discrete_choice grammar.) -P.S. I should point out that even this grammar introduces an incompatibility, in that: +P.S. I should point out that even this grammar introduces an incompatibility, in +that: when X in Natural => will now need parentheses. when (X in Natural) => -But this seems *very* unlikely in a case statement (who other than ACATS test writers writes Boolean case statements?), while the modular case is just unlikely; the example given above using Win32 window styles does not seem improbable. +But this seems *very* unlikely in a case statement (who other than ACATS test +writers writes Boolean case statements?), while the modular case is just +unlikely; the example given above using Win32 window styles does not seem +improbable. ****************************************************************

Questions? Ask the ACAA Technical Agent