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

--- ai05s/ai05-0158-1.txt	2009/11/03 00:19:50	1.5
+++ ai05s/ai05-0158-1.txt	2010/01/21 05:25:54	1.6
@@ -1,6 +1,7 @@
-!standard 3.8.1(5)                                 09-11-02    AI05-0158-1/03
+!standard 3.8.1(5)                                 10-01-20    AI05-0158-1/04
 !standard 4.4(3)
 !standard 4.5.2(3)
+!standard 4.5.2(5)
 !standard 4.5.2(27)
 !class Amendment 09-06-07
 !status work item 09-06-07
@@ -11,17 +12,25 @@
 
 !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.
+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. Memberships should be more flexible.
+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
 
@@ -54,7 +63,7 @@
      simple_expression [relational_operator simple_expression]
 
   relation ::=
-     simple_expression [not] in choice_list
+     simple_expression [not] in membership_choice_list
 
   membership_choice_list ::= membership_choice {'|' membership_choice}
 
@@ -69,15 +78,34 @@
 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.
+
 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.
+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.
+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)
 
 !discussion
 
@@ -97,6 +125,18 @@
 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.
+
+[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.)]
+
 !example
 
 (See proposal.)
@@ -227,6 +267,19 @@
 If they're only for static discrete types (as in case statements, based on
 Tucker's responses), then I surely agree that they're easy to implement. I'm not
 so sure in other cases.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, March 30, 2009  10:11 PM
+
+> If they're only for static discrete types (as in case statements, 
+> based on Tucker's responses), then I surely agree that they're easy to 
+> implement. I'm not so sure in other cases.
+
+I gave a semantic equivalence, and no, it is not acceptable to limit these to
+static values, but of course they are limited to discrete types, that goes
+without saying.
 
 ****************************************************************