CVS difference for ai05s/ai05-0158-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file 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