--- ai05s/ai05-0158-1.txt 2010/06/14 01:24:50 1.8 +++ ai05s/ai05-0158-1.txt 2010/11/13 01:26:26 1.9 @@ -1,8 +1,10 @@ -!standard 3.8.1(5) 10-01-20 AI05-0158-1/04 +!standard 3.8.1(5) 10-10-21 AI05-0158-1/05 !standard 4.4(3) !standard 4.5.2(3) -!standard 4.5.2(5) +!standard 4.5.2(4) !standard 4.5.2(27) +!standard 4.5.2(28) +!standard 4.9(11) !class Amendment 09-06-07 !status work item 09-06-07 !status received 09-03-30 @@ -47,40 +49,52 @@ !wording -Modify 3.8.1 (5) as follows: +Replace 3.8.1 (5): discrete_Choice ::= choice_expression | discrete_Range | others -Modify 4.4(3) as follows: +Replace 4.4(3): - expression := relation {logical_operator relation} - - choice_expression := - choice_relation {logical_operator choice_relation} - - - choice_relation ::= - simple_expression [relational_operator simple_expression] - - relation ::= - simple_expression [not] in membership_choice_list - - membership_choice_list ::= membership_choice {'|' membership_choice} - - membership_choice ::= choice_expression | range | subtype_mark - - logical_operator ::= and | and then | or | or else | xor - - -Add after 4.5.2(3): (Name Resolution Rules) - -If the membership_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. + 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 + choice_expression ::= simple_expression -Add after 4.5.2 (5) (Static semantics) - -The expected type of a choice_expression in a membership_choice is any type. +Replace 4.5.2(3): (Name Resolution Rules) + + The tested type of a membership test is the type of the range + or the type determined by the subtype_mark. 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 type; if + untagged, the expected type for the simple_expression is the + tested type. + +with + + The tested type of a membership test shall be 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. + + 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 + type; if untagged, the expected type for the simple_expression is + the tested type. The expected type of a choice_expression in a + membership_choice, and of a simple_expression of a range in a + membership_choice, is the tested type of the membership operation. + +Append after 4.5.2(4) (Legality Rules): + + If a membership test includes one or more choice expressions and + 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: @@ -107,10 +121,33 @@ (followed by para. 29-30) +Replace 4.9(11) [definition of a static expression] + + a membership test whose simple_expression is a static expression, + and whose range is a static range or whose subtype_mark denotes a + static [(scalar or string)] subtype; + +with + + a membership test whose simple_expression is a static expression, + and whose membership choice list consists of only static choice + expressions, static ranges, and subtype marks each denoting + a static [(scalar or string)] subtype; + + +Append after 4.9(37/3) [another bulleted item in the definition of + "statically unevaluated": + + - a choice_expression (or an expression of a range which occurs + as a member of a membership_choice list) of a static membership + test which is preceded in the enclosing membership_choice list by + another item whose individual membership test (see 4.5.2) + statically yields True. + !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 +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: @@ -131,12 +168,15 @@ the type has no primitive equality a membership test over a list of expressions is illegal. -[Editor's note: This decision brings visibility into the legality of membership -operations. That seems like a lousy choice (pun intended). Personally, I would -prefer the inconsistency. (Well, I'd prefer AI-153-2 instead of this one, which -would require these to be discrete only, but make them work *everywhere*. But -that's a separate issue.)] +We define choices to be "statically unevaluated" so that X in Y|Z is +completely equivalent to X = Y or else X = Z. For example, we want +to allow + + Integer'Last in (2**32 -1) | (2**64 -1) + +in the case where Integer'Last equals the first value. + !example (See proposal.) @@ -1502,6 +1542,346 @@ possible. (I want it to be a *lot* more non-specific in this case, requiring the tested type to be determinable without any context or reference to the expression. But that's a separate discussion.) + +**************************************************************** + +From: Tucker Taft +Date: Tuesday, October 5, 2010 5:30 PM + +We simplified the grammar for expression in 4.4 as follows: + + expression := relation {logical_operator relation} + + logical_operator ::= and | and then | or | or else | xor + +Unfortunately, this is not equivalent to the old grammar. +We will need to add another sentence saying that the logical_operators in a +sequence of + + relation logical_operator relation logical_operator relation ... + +must all be the *same* logical_operator. + +**************************************************************** + +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, +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). + +It seems like we need a rule saying if/when these things are static expressions. + +Why did somebody change the syntax from: + +2 expression ::= + relation {and relation} | relation {and then relation} + | relation {or relation} | relation {or else relation} + | relation {xor relation} + +to: + + expression := relation {logical_operator relation} + +? + +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: + + logical_operator ::= and | and then | or | or else | xor + +makes no sense because "and then" and "or else" are not operators. + +**************************************************************** + +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. + + type Y is range 1..10; + if X in Y ... + +or: + + type Enum is (Y); + if X in Y ... -- I assume this is legal, and means "X = Y". + +**************************************************************** + +From: Steve Baird +Date: Thursday, October 21, 2010 3:42 PM + +[Note: The following makes up version /05 of this AI. - Editor] + +Some further wording improvments (I hope). + +The current proposal proposes the following changes: + + Add after 4.5.2(3): (Name Resolution Rules) + + If the membership_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 after 4.5.2 (5) (Static semantics) + + The expected type of a choice_expression in a membership_choice is + any type. + +Replace these proposed changes with the following: + + Replace 4.5.2(3): (Name Resolution Rules) + + The tested type of a membership test is the type of the range + or the type determined by the subtype_mark. 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 type; if + untagged, the expected type for the simple_expression is the + tested type. + + with + + The tested type of a membership test shall be 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. + + 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 + type; if untagged, the expected type for the simple_expression is + the tested type. The expected type of a choice_expression in a + membership_choice, and of a simple_expression of a range in a + membership_choice, is the tested type of the membership operation. + +Rationale: + The previous proposal didn't work well with universal types, as in + X, Y : Integer := ...; + Flag : Boolean := X in Y | 10; + + The revised wording is based on the name resolution rules for + conditional expressions. + +==== + +The current proposal proposes the following changes: + + Modify 4.4(3) as follows: + expression := relation {logical_operator relation} + choice_expression := choice_relation {logical_operator choice_relation} + choice_relation ::= + simple_expression [relational_operator simple_expression] + relation ::= simple_expression [not] in membership_choice_list + membership_choice_list ::= membership_choice {'|' membership_choice} + membership_choice ::= choice_expression | range | subtype_mark + logical_operator ::= and | and then | or | or else | xor + +Replace these proposed changes with the following: + + Modify 4.4(3) as follows: + 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 + choice_relation ::= simple_expression + + +Rationale: + The previous proposal would have allowed + X and then Y or else Z + and classified "and then" and "or else" as operators. + These mistakes were not intended. + The current proposal resolves the + case X is + when A in B | C => + syntactic ambiguity by requiring that a + choice expression must be a simple expression. + + [Conflict of interest disclosure: I am an investor in + a major supplier of parentheses] + +==== + +Append after 4.5.2(4) (Legality Rules): + + If a membership test includes one or more choice expressions and + the tested type of the membership test is limited, then the + tested type of the membership test shall have a visible + primitive equality operator. + +Rationale: + The dynamic semantics of a membership test should not be defined + in terms of a call to a nonexistent (or non-visible) function. + +==== + +Replace 4.9(11) [definition of a static expression] + + a membership test whose simple_expression is a static expression, + and whose range is a static range or whose subtype_mark denotes a + static [(scalar or string)] subtype; + +with + + a membership test whose simple_expression is a static expression, + and whose membership choice list consists of only static choice + expressions, static ranges, and subtype marks each denoting + a static [(scalar or string)] subtype; + + +Append after 4.9(37/3) [another bulleted item in the definition of + "statically unevaluated": + + - a choice_expression (or an expression of a range which occurs + as a member of a membership_choice list) of a static membership + test which is preceded in the enclosing membership_choice list by + another item whose individual membership test (see 4.5.2) + statically yields True. + +Rationale: + Given + X : constant Integer := 23; + Flag : constant Boolean := X in 19 | 23 | Integer'Last + we want Flag's value to be static. + + Following the example of short-circuit expressions, we want + to allow + + Integer'Last in (2**32 -1) | (2**64 -1) + + in the case where Integer'Last equals the first value. + + The "statically unevaluated" wording is sloppy, although I + the intended meaning seems clear. I don't see a good way to + express this more precisely without adding quite a bit more + wording, but it is not clear that the wording suggested here + is really adequate. + +**************************************************************** + +From: Steve Baird +Date: Thursday, October 21, 2010 3:58 PM + +> The current proposal resolves the +> case X is +> 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. 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. + +Perhaps just a stated-in-English non-BNF syntax rule something like + If a discrete_choice includes a membership test, then it + shall include a simple_expression which includes the + membership test. +? + +**************************************************************** + +From: Bob Duff +Date: Thursday, October 21, 2010 4:06 PM + +> discrete_choice ::= expression | discrete_range | others + +I think the predicates proposal touches this area... + +**************************************************************** + +From: Steve Baird +Date: Thursday, October 21, 2010 6:16 PM + +>> The current proposal resolves the +>> case X is +>> 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. + +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 + + 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. + +**************************************************************** + +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. + +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. + +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: + + + expression := relation {and relation} + | relation {or relation} + | relation {xor relation} + | relation {and then relation} + | relation {or else relation} + + choice_expression := choice_relation {and choice_relation} + | choice_relation {or choice_relation} + | choice_relation {xor choice_relation} + | choice_relation {and then choice_relation} + | choice_relation {or else choice_relation} + + choice_relation ::= + simple_expression [relational_operator simple_expression] + + 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. + +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: + 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. ****************************************************************

Questions? Ask the ACAA Technical Agent