--- 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. ****************************************************************

Questions? Ask the ACAA Technical Agent