--- ai05s/ai05-0158-1.txt 2009/06/09 05:23:08 1.3 +++ ai05s/ai05-0158-1.txt 2009/11/03 00:12:17 1.4 @@ -1,6 +1,6 @@ -!standard 4.4 (3) 09-06-07 AI05-0158-1/01 +!standard 4.4 (3) 09-11-01 AI05-0158-1/02 !standard 4.5.2(3) -!standard 4.5.2(30/2) +!standard 4.5.2(27) !class Amendment 09-06-07 !status work item 09-06-07 !status received 09-03-30 @@ -30,56 +30,55 @@ !wording -Modify 4.4(3) as follows: +Modify 4.4(3) as follows: + + restricted_expression := + restricted_relation {logical_operator restricted_relation} + logical_operator ::= and | and then | or | or else | xor + + restricted_relation ::= + simple_expression [relational_operator simple_expression] + + relation ::= + simple_expression [not] in choice_list + choice_list ::= choice {'|' choice} + choice ::= restricted_expression | range | subtype_mark + +[modify the production for discrete_choice in 3.8.1 (5) accordingly] + +Add after 4.5.2(3): (Name Resolution Rules) + +If the choice_list in a membership operation has more that one choice, then +all choices must have a single common type, which is the tested type of the +operation. + +Modify 4.5.2(27) as follows: + +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 tests : +if a choice is a restricted expression the +corresponding test is an equality operation, otherwise it is a membership test +whose right operand is the corresponding range or subtype_mark. -relation ::= - simple_expression [not] in choice_list - choice_list ::= choice {'|' choice} - choice ::= simple_expression | range | subtype_mark - -[Editor's comment: This grammar is ambiguous if the expression is used -in a discrete_choice_list (that is, in a variant part, case statement, -or array aggregate). See the !discussion section.] - -Add after 4.5.2(3): (Name Resolution Rules) - -If the choice_list in a membership operation has more that one choice, then -all choices must have a single common type, which is the tested type of the -operation. - -Add somewhere in 4.5.2(28-31): (Dynamic Semantics) - -The left operand is elaborated first. -If the choice_list has more that one choice, the operation is equivalent to a -short-circuit sequence of tests : if a choice is a simple expression the -corresponding test is an equality operation, otherwise it is a membership test -whose right operand is the corresponding range or subtype_mark. - -[Editor's comment: The first sentence contradicts 4.5.2(27). Is that really -what we want? We ought to reword this to fit in with the existing wording.] - !discussion - -The new syntax introduces an ambiguity in case statements whose expression is -boolean: - X : Boolean := .. - case X is - when Y in 1..10 | 20 => -- ambiguous: - -- could be (Y in 1..10) | 20 - -- which is otherwise type-incorrect - -The ambiguity only arises if the case expression is boolean and if the -left operand and expressions are all static, which seems extremely rare. -The simplest is to state that a membership operation with multiple expressions -that appears in a case alternative must be parenthesized. - -[Editor's comment: The same surely is true of variant parts, and is *almost* -true of array aggregates (there is no requirement for staticness there). -Also note that you can write legal such expressions, but they would only -happen in ACATS tests: when X in True | False => (!). I prefer the -"restricted_expressions" alternative suggested by Robert Dewar, see the -!appendix.] +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. !example @@ -546,5 +545,16 @@ implementation of set membership. It took only 10 lines of code, and with this change we get zero regressions on our own sources and our regression suite (when we force this restriction on unconditionally). + +**************************************************************** + +From: Ed Schonberg +Date: Sunday, November 1, 2009 10:25 AM + +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. + +[Editor's note: This is version /02 of the AI.] ****************************************************************

Questions? Ask the ACAA Technical Agent