CVS difference for ai05s/ai05-0158-1.txt
--- 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