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

--- ai05s/ai05-0188-1.txt	2010/01/09 01:31:30	1.2
+++ ai05s/ai05-0188-1.txt	2010/02/04 02:31:24	1.3
@@ -1,4 +1,4 @@
-!standard 4.5.7 (0)                                10-01-07  AI05-0188-1/02
+!standard 4.5.7 (0)                                10-02-03  AI05-0188-1/03
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
@@ -46,7 +46,7 @@
         Add_To_Bowl(Fruit, Bowl);
     end Add_To_Fruit_Salad;
 
-We would like to remove those assertions, and make them into preconditions:
+We would like to remove those Assert pragmas, and make them into preconditions:
 
     procedure Add_To_Fruit_Salad(
       Fruit : in out Fruit_Type; Bowl : in out Bowl_Type)
@@ -80,16 +80,29 @@
 
 !wording
 
-In 4.4(7), add:
+Add a bullet following 4.3.3(14):
 
-primary ::=
-   numeric_literal | null | string_literal | aggregate  | name |
-   allocator | (expression) | conditional_expression
+* For a conditional_expression or case_expression, the applicable index
+  constraint for each *dependent_*expression is that, if any, defined for the
+  conditional or case_expression;
 
+(Minor detail: AI05-0147-1 suggests this should go after (15), but it seems
+better after (14).)
+
+Modify 4.4(1) to add conditional and case expressions, as follows:
+
+    In this International Standard, the term "expression" refers to a construct
+    of the syntactic category expression or of any of the following
+    categories: relation, simple_expression, term, factor, primary,
+    conditional_expression, case_expression.
+
 Add a new clause:
 
-4.5.7 Conditional expressions
+4.5.8 Case expressions
 
+A case_expression selects for evaluation one of a number of alternative
+expressions; the chosen alternative is defined by the value of an expression.
+
     Syntax
 
 case_expression ::=
@@ -100,35 +113,83 @@
 
 case_expression_alternative ::=
     when discrete_choice_list =>
-        expression
+        *dependent*_expression
+
+Wherever the Syntax Rules allow an expression, a case_expression may be used in
+place of the expression, so long as it is immediately surrounded by parentheses.
+
+[AARM: Note that the above is the same rule as for conditional_expressions; see
+4.5.7 for further discussion.]
+
+    Name Resolution Rules
+
+The expected type for the expression and the discrete_choices are as for case
+statements (see 5.4).
+
+If a case_expression is expected to be of a type T, the expected type for each
+*dependent_*expression of the case_expression is T. If a case_expression shall
+resolve to a type T, each dependent_expression shall resolve to T.
+
+    Legality Rules
+
+The expressions and discrete_ranges given as discrete_choices of a
+case_expression shall be static. Redundant[A discrete_choice others, if present,
+shall appear alone and in the last discrete_choice_list.]
 
-???I don't have time to write up all the rules right now.
-Let's first see if this idea will fly at all.
+The possible values of the expression shall be covered as for case statements
+(see 5.4).
 
-Basically, the rules can be patterned after the rules for case statements,
-especially the full coverage rules. "when others" is allowed, and as for case
-statements, should be used with discretion.
+As for case statements, two distinct discrete_choices of a case_expression shall
+not cover the same value.
 
-We also want to add it to qualified_expression, as for conditional_expression:
+If the expected type of a case_expression is any type in a class of types
+(instead of a particular type), all *dependent_*expressions of the
+case_expression shall have the same type.
 
-qualified_expression ::=
-   subtype_mark'(expression) | subtype_mark'aggregate |
-   subtype_mark'conditional_expression
-   subtype_mark'case_expression
+If the expected type of a case_expression is a specific tagged type, all of the
+*dependent_*expressions of the case_expression shall be dynamically tagged, or
+none shall be dynamically tagged; the case_expression is dynamically tagged if
+all of the *dependent_*expressions are dynamically tagged, is tag-indeterminate
+if all of the *dependent_*expressions are tag-indeterminant, and is statically
+tagged otherwise.
 
-There is nothing corresponding to the implicit "else False" for
+AARM Note: There is nothing corresponding to the implicit "else False" for
 conditional_expressions.
 
-We need rules for static expressions. There are two parts. One is left for
-later.
+    Dynamic Semantics
 
-The other part is based on the changes proposed in AI05-0147-1. We need to add
-an additional bullet to the definition of "statically unevaluated":
+For the execution of a case expression, the expression specified after case is
+first evaluated.
 
-* an expression of a case expression alternative where the expression of
-  the enclosing case expression is static and has a value that is
-  not covered by the discrete_choice_list of the case expression alternative.
+If the value of the expression is covered by the discrete_choice_list of some
+case_expression_alternative, then the *dependent*_expression of the _alternative
+is evaluated, and this is the value of the case_expression.
 
+Otherwise (the value is not covered by any discrete_choice_list, perhaps due to
+being outside the base range), Constraint_Error is raised.
+
+================
+
+Add after 4.9(12):
+
+* A case_expression all of whose conditions and dependent_expressions are
+  static expressions;
+
+AI05-0147-1 calls for the replacement of 4.9(33).
+Add one more bullet:
+
+* a *dependent_*expression of a case_expression whose
+  expression is static and not covered by the
+  corresponding discrete_choice_list.
+
+Modify 7.5(2.1/2):
+
+In the following contexts, an expression of a limited type is not permitted
+unless it is an aggregate, a function_call, [or ]a parenthesized expression or
+qualified_expression whose operand is permitted by this rule{, or a conditional_
+or case_expression all of whose *dependent_*expressions are permitted by this
+rule}:
+
 !discussion
 
 !examples
@@ -154,5 +215,202 @@
 > Case expressions are added to Ada.
 
 looks good to me, I am going to go ahead and implement this in GNAT
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 3, 2010  4:26 PM
+
+Here's my homework on AI05-0188-1 Case expressions.
+
+Minor changes to !problem, major changes to !wording.
+
+[This is version /03 of the AI - Editor.]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 3, 2010  4:35 PM
+
+Might you consider defining:
+
+   conditional_expression ::= if_expression | case_expression
+
+   if_expression ::= IF ...
+
+   case_expression ::= CASE ...
+
+This would seem more consistent, and would eliminate the awkward
+"conditional_expression or case_expression" appearing all over the place.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 3, 2010  5:19 PM
+
+> Might you consider defining:
+>
+>    conditional_expression ::= if_expression | case_expression
+>
+>    if_expression ::= IF ...
+>
+>    case_expression ::= CASE ...
+
+Yes, I might.
+
+> This would seem more consistent, and would eliminate the awkward
+> "conditional_expression or case_expression"
+> appearing all over the place.
+
+If we could get a concensus that both of these AIs are 'in', then we could
+simplify them by combining them, and write the common wording stuff just once.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 3, 2010  4:28 PM
+
+The proposed syntax for case expressions separates alternatives with commas.
+Robert thinks perhaps we should leave them out -- not sure. Comments?  I am
+(mildly) in favor of keeping the commas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 3, 2010  4:32 PM
+
+I am not sure I like the commas, though that's what I have implemented for now,
+consider
+
+    A := (if    X = Red   then 3
+          elsif X = Green then 4
+          elsif X = Blue  then 5
+          else                 6);
+
+    A := (case X is
+          when Red   => 3,
+          when Green => 4,
+          when Blue  => 5,
+          others     => 6);
+
+Or should we try to have a more parallel syntax
+
+    A := (case X is
+          when Red   => 3
+          when Green => 4
+          when Blue  => 5
+          others     => 6);
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 3, 2010  4:40 PM
+
+I prefer the commas.  I don't think everyone is going to format their output the
+way you have here, and it looks better to me to have commas when formatted as
+follows:
+
+    (case X is when A => 5, when B => 6, when others => 7)
+
+If it were "else when" then I could see dropping the commas, but "when A => 5
+when B => 6" is harder to read without the commas in my view.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 3, 2010  4:49 PM
+
+OK, commas fine by me (and less implementation work for sure at this stage,
+since already done).
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, February 3, 2010  5:40 PM
+
+> Minor changes to !problem, major changes to !wording.
+
+Looks good.
+
+One spelling nit:
+
+> Whereever the Syntax Rules allow an expression,
+
+Whereever => Wherever
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 3, 2010  6:38 PM
+
+Randy, do you take care of this sort of editorial thing?
+
+Anyway, note that this typo was copied from AI-147, so should be fixed in both.
+Unless we combine them!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 3, 2010  7:56 PM
+
+I'll take care of it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 3, 2010  8:21 PM
+
+...
+> Add a bullet following 4.3.3(14):
+>
+> * For a conditional_expression or case_expression, the applicable index
+>   constraint for each *dependent_*expression is that, if any, defined
+>   for the conditional or case_expression;
+>
+> (Minor detail: AI05-0147-1 suggests this should go after (15), but it
+> seems better after (14).)
+
+I put it after (15) because these are semantically parenthesized expressions,
+and as such, it seemed best to group them with it (and after it). I did that
+consistently (for instance, in the wording for limited expressions). Not a big
+deal either way.
+
+...
+> Modify 7.5(2.1/2):
+>
+> In the following contexts, an expression of a limited type is not
+> permitted unless it is an aggregate, a function_call, [or ]a
+> parenthesized expression or qualified_expression whose operand is
+> permitted by this rule{, or a conditional_ or case_expression all of
+> whose *dependent_*expressions are permitted by this rule}:
+>
+> AARM Note: There is nothing corresponding to the implicit "else False"
+> for conditional_expressions.
+
+This AARM note seems to be in the wrong place; I can't imagine what it has to do
+with expressions of limited types. But it might make sense somewhere in 4.5.8.
+
+Tucker later writes:
+
+> Might you consider defining:
+>
+>   conditional_expression ::= if_expression | case_expression
+>
+>   if_expression ::= IF ...
+>
+>   case_expression ::= CASE ...
+>
+> This would seem more consistent, and would eliminate the awkward
+"conditional_expression or
+> case_expression" appearing all over the place.
+
+That would be OK, but I would object to combining the sections for the kinds of
+expressions. We keep the legality and semantic rules for case and if statements
+separate, and I would think we want to do that here as well.
+
+I also have to wonder if this solution works very well for
+quantified_expressions, which also have to be referred to in many of these
+places (although the semantics is somewhat different). Would it look weird to
+combine two of the three new kinds of expressions, and not the third??
 
 ****************************************************************