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

Differences between 1.11 and version 1.12
Log of other versions for file ai05s/ai05-0147-1.txt

--- ai05s/ai05-0147-1.txt	2010/02/04 07:11:43	1.11
+++ ai05s/ai05-0147-1.txt	2010/02/23 07:31:06	1.12
@@ -1,5 +1,6 @@
-!standard 4.3.3(15)                                    10-02-01  AI05-0147-1/08
+!standard 4.3.3(15)                                    10-02-04  AI05-0147-1/09
 !standard 4.4(1)
+!standard 4.4(7)
 !standard 4.5.7(0)
 !standard 4.7(2)
 !standard 4.7(3)
@@ -105,7 +106,13 @@
     categories defined below]{following categories: relation,
     simple_expression, term, factor, primary, conditional_expression}.
+Replace 4.4(7) with:
+primary ::=
+   numeric_literal | NULL | string_literal | aggregate
+ | name | qualified_expression | allocator | (expression)
+ | (conditional_expression)
 Add a new clause:
 4.5.7 Conditional expressions
@@ -121,20 +128,19 @@
 Wherever the Syntax Rules allow an expression, a conditional_expression may be
 used in place of the expression, so long as it is immediately surrounded by
+AARM Discussion: The syntactic category conditional_expression appears only
+as a primary that is parenthesized. The above rule allows it to additionally
+be used in other contexts where it would be directly surrounded by
-AARM Discussion: The syntactic category conditional_expression is not explicitly
-referenced by any other BNF syntax rules. The above rule "plugs it in" to the
-rest of the grammar, by allowing conditional_expression to play the syntactic
-role of expression, except that it must be parenthesized.
-One of the possibilities for primary is (expression). The above rule implies
-that we can use (conditional_expression) instead, so the following are
-syntactically legal:
+The grammar mades the following directly legal:
     A := (if X then Y else Z); -- parentheses required
     A := B + (if X then Y else Z) + C; -- parentheses required
-The following procedure calls are syntactically legal:
+The following procedure calls are syntactically legal; the first uses
+the above rule to eliminate the redundant parentheses found in the second:
     P(if X then Y else Z);
     P((if X then Y else Z)); -- redundant parentheses
@@ -152,9 +158,12 @@
 because in these latter cases, the conditional_expression is not immediately
 surrounded by parentheses (which means on both sides!).
-The above English-language rule is equivalent to modifying the BNF as follows,
-as far as syntax goes:
+The English-language rule applies in all places that could surround an
+expression with parentheses, including pragma arguments, type conversion
+and qualified expression operands, and array index expressions.
+The above English-language rule is equivalent to modifying the BNF as follows:
     expression_within_parens ::=
       expression |
@@ -206,7 +215,7 @@
 AARM Implementation Note: Implementers are cautioned to consider error
 detection when implementing the syntax for conditional_expressions.
-Conditional_expressions and if_statements are very similar syntactally,
+Conditional_expressions and if_statements are very similar syntactically,
 and simple mistakes can appear to change one into the other, potentially
 causing errors to be moved far away from their actual location.
@@ -239,7 +248,7 @@
 dynamically tagged, or none shall be dynamically tagged; the
 conditional_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
+the *dependent_*expressions are tag-indeterminate, and is statically tagged
 [Editor's note: We don't try to define the type of the conditional expression;
@@ -331,9 +340,9 @@
 compiler (the first one) be obvious.
 The obvious choice is to surround a conditional expression with parentheses.
-This is already a common Ada design choice, and will be familar to Ada
+This is already a common Ada design choice, and will be familiar to Ada
 programmers. Other choices, such as using square brackets (currently unused in
-Ada), or using syntax other than "if", would be less familar and would cause
+Ada), or using syntax other than "if", would be less familiar and would cause
 programmers a confusion as to which syntax to use in a given location.
 Thus, we design conditional expressions to work like a fancy set of parentheses.
@@ -347,7 +356,7 @@
     Proc ((if A then B else C));
 We thus adopt rules to allow elimination of the extra parentheses in all contexts
-where they are directly nested and thus two sets of parantheses are directly adjacent.
+where they are directly nested and thus two sets of parentheses are directly adjacent.
     pragma Assert (if A then B else C);
     Proc (if A then B else C);
@@ -363,7 +372,7 @@
 We wanted to allow the above case, but it becomes ambiguous for case expressions
 (AI05-188-1), and we want to use the same rules for all kinds of expressions.
-More aggresive rules would make it much harder to create unambiguous syntax rules.
+More aggressive rules would make it much harder to create unambiguous syntax rules.
 Most likely, the parentheses requirements would have to be enforced as legality
 rules. That would have the effect of making syntax error correction much harder.
 Consider the following syntactically incorrect Ada code:
@@ -382,64 +391,6 @@
-We considered using syntax changes to describe the grammar, but that was too complex.
-The Implementation Note in 4.4 gives a basic explanation. Note that just leaving
-the parentheses out everywhere makes expressions unavoidably ambiguous, so
-implementations will most likely want to use a grammar like the suggested changes
-in place of the language-defined rules. The following was the proposed grammar
-In 4.4, define:
-    expression_within_parentheses ::=
-      expression |
-      conditional_expression
-In each of the following change expression to expression_within_parentheses.
-    primary ::= (expression_within_parentheses)
-    qualified expression ::=
-      subtype_mark'(expression_within_parentheses)
-    type_conversion ::=
-      subtype_mark (expression_within_parentheses)
-    attribute_designator ::=
-      identifier[(*static*_expression_within_parantheses)]
-    range_attribute_designator ::=
-      Range[(*static*_expression_within_parentheses)]
-    entry_index ::= expression_within_parentheses
-Add productions to the following:
-    actual_parameter_part ::= (conditional_expression)
-    generic_actual_part   ::= (conditional_expression)
-    discriminant_constraint ::= (conditional_expression)
-For indexed components, replace
-   indexed_component ::= prefix(expression {, expression})
-   index_expression_list ::= (expression {, expression}) | (conditional_expression)
-   indexed_component ::= prefix index_expression_list
-For pragmas, replace
-   pragma ::=
-    Pragma identifier
-     [(pragma_argument_association {, pragma_argument_association})];
-    pragma_argument_association_list ::=
-     (pragma_argument_association {, pragma_argument_association})
-      | (conditional_expression)
-    pragma ::= Pragma identifier [pragma_argument_association_list] ;
 Resolution of a conditional_expression also follows the model of parentheses.
 (That's made harder by the complete absence of such rules in the Ada Standard,
 so there is nothing to copy.)
@@ -466,6 +417,15 @@
     if (if Cond then Var > 10 else Foo) then ... -- Illegal by legality rule.
+Note the we do allow the types to differ if a unique type is identified by the
+context; this allows implicit conversions (including to class-wide and access
+types) to work properly. If the types had to be the same, all of the
+following would be illegal:
+    (if Cond then Var else 0)
+    (if Ptr /= null then Ptr.all else null)
+    T'Class'(if Cond then DT'(A) else T'(B) -- Where DT is derived from T
+which is definitely not what we want.
 We also have a rule to disallow mixing statically tagged and dynamically
 tagged expressions in the same conditional_expression; that makes enforcing
 3.9.2(8) possible.
@@ -517,7 +477,7 @@
     statically moot
-The term choosen seems OK, but none are that great.
+The term chosen seems OK, but none are that great.
@@ -8223,5 +8183,27 @@
 Indeed. Even an ordinary application programmer will understand it. Please
 let's stick with that.
+From: Tucker Taft
+Sent: Thursday, February  4, 2010  9:06 PM
+As we discussed in a phone call today, I would recommend that we add
+"(conditional_expression)" to the grammar for primary, while still retaining
+the nice wording that has been proposed for allowing conditional_expression
+to be used in other contexts as well.  This way the naive user will see that
+conditional_expression does tie into the grammar in a basic way, and the
+sophisticated user can take advantage of the additional capability to use it
+in other contexts that already are parenthesized.
+From: Robert Dewar
+Sent: Friday, February  5, 2010  7:10 AM
+Another way of viewing this exception is not that it allows conditional expressions
+to be used as other than primaries, but just that in certain contexts this primary
+may appear without its parentheses.

Questions? Ask the ACAA Technical Agent