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

--- ai05s/ai05-0147-1.txt	2010/01/21 05:13:18	1.8
+++ ai05s/ai05-0147-1.txt	2010/01/22 00:32:47	1.9
@@ -1,4 +1,5 @@
-!standard 4.4(7)                                    10-01-19  AI05-0147-1/06
+!standard 4.3.3(15)                                    10-01-21  AI05-0147-1/07
+!standard 4.4(7)
 !standard 4.5.7(0)
 !standard 4.7(2)
 !standard 4.7(3)
@@ -89,20 +90,26 @@
 
 !wording
 
+Change the . to a ; at the end of 4.3.3(15), and add a following bullet:
+
+* For a conditional_expression, the applicable index constraint for
+  each *dependent_*expression is that, if any, defined for the
+  conditional_expression.
+
 Replace 4.4(7) by:
 
 primary ::=
    numeric_literal | null | string_literal | aggregate
- | name | allocator | (expression_within_parens)
+ | name | allocator | (expression_within_parentheses)
 
 Add after 4.4(7):
 
-expression_within_parens ::=
+expression_within_parentheses ::=
    expression
  | conditional_expression
 
 If an expression appears directly inside of another set of parentheses,
-an expression_within_parens can be used instead. Redundant[This allows
+an expression_within_parentheses can be used instead. Redundant[This allows
 the use of a single set of parentheses in such cases.]
 
 AARM Reason: We could have written this as a syntax rule (as we did in
@@ -114,14 +121,14 @@
 AARM Ramification: This rule applies to
 attribute_designator and range_attribute_designator (4.1.4),
 type_conversion (4.6), entry_index (9.5.2), and to single (positional)
-items in  pragma (2.8), discriminant_constraint (3.7.1),
+items in pragma (2.8), discriminant_constraint (3.7.1),
 indexed_component (4.1.1), actual_parameter_part (6.4),
 and generic_actual_part (12.3).
 
 AARM Implementation Note: In order to avoid ambiguity, and preserve the
 ability to do useful error correction, it is recommended that the grammar
 for all of the above productions be modified to reflect this rule. For the
-four productions, replacing expression with expression_within_parens
+four productions, replacing expression with expression_within_parentheses
 in the grammar will have the correct effect; for the latter productions,
 adding a parallel singleton_list ::= ( conditional_expression ) will have
 the correct effect without adding any ambiguity.
@@ -143,7 +150,7 @@
 A condition is expected to be of any boolean type.
 
 If a conditional_expression is expected to be of a type T, the expected type for
-each dependent_expression of the conditional_expression is T. If a
+each *dependent_*expression of the conditional_expression is T. If a
 conditional_expression shall resolve to a type T, each dependent_expression
 shall resolve to T.
 
@@ -155,17 +162,17 @@
     Legality Rules
 
 If the expected type of a conditional_expression is any type in a class of types
-(instead of a particular type), all dependent_expressions of the
+(instead of a particular type), all *dependent_*expressions of the
 conditional_expression shall have the same type.
 
-If there is no "else" dependent_expression, all of the dependent_expressions of
+If there is no "else" *dependent_*expression, all of the *dependent_*expressions of
 the conditional_expression shall be of a boolean type.
 
 If the expected type of a conditional_expression is a specific tagged type, all
-of the dependent_expressions of the conditional_expression shall be dynamically
+of the *dependent_*expressions of the conditional_expression shall be 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,
+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.
 
 [Editor's note: We don't try to define the type of the conditional expression;
@@ -179,7 +186,7 @@
 if, and any conditions specified after elsif, are evaluated in succession
 (treating a final else as elsif True then), until one evaluates to True or
 all conditions are evaluated and yield False. If a condition evaluates to
-True, the associated dependent_expression is evaluated and its value
+True, the associated *dependent_*expression is evaluated and its value
 is the value of the expression. Otherwise, the value of the expression
 is True.
 
@@ -190,11 +197,11 @@
 Replace 4.7(2) by:
 
 qualified_expression ::=
-   subtype_mark'(expression_within_parens) | subtype_mark'aggregate
+   subtype_mark'(expression_within_parentheses) | subtype_mark'aggregate
 
 In 4.7(3), modify the start of the paragraph:
 
-The *operand* (the {expression_within_parens}[expression], or aggregate)
+The *operand* (the {expression_within_parentheses}[expression], or aggregate)
 shall...
 
 Add after 4.9(12):
@@ -209,19 +216,19 @@
 * the right operand of a static short-circuit control form whose
   value is determined by its left operand; or
 
-* a dependent_expression of a conditional_expression whose associated
+* a *dependent_*expression of a conditional_expression whose associated
   condition is static and equals False; or
 
-* a condition or dependent_expression of a conditional_expression
+* a condition or *dependent_*expression of a conditional_expression
   where the condition corresponding to at least one preceding
-  dependent_expression of the conditional_expression is static and equals
+  *dependent_*expression of the conditional_expression is static and equals
   True.
 
 AARM Discussion: We need the "of the conditional_expression" here so there
 is no confusion for nested conditionals; this rule only applies to the
-conditions and dependent_expressions of a single conditional expression.
+conditions and *dependent_*expressions of a single conditional expression.
 
-AARM Reason: We need the last bullet so that only a single dependent_expression
+AARM Reason: We need the last bullet so that only a single *dependent_*expression
 is evaluated in a static conditional expression if there is more than one
 condition that evaluates to True. The part about conditions makes
     (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min)
@@ -233,17 +240,6 @@
 is performed exactly, without performing Overflow_Checks. For a static
 expression that is evaluated:
 
-[Editor's note: Adam Beneschan suggested in AC-0171 to add another case to the
-list now known as "statically unevaluated" - an aggregate others clause known
-to denote zero elements:
-
-  * it is the expression of an array_component_association whose
-    discrete_choice_list is statically known to denote zero
-    components.
-
-I don't think this level of detail is common enough to add to the language, but
-the introduction of the "statically unevaluated" term would make it easy to add
-this here if desired.]
 
 Delete 5.3(3-4) [they were moved to 4.5.7]
 
@@ -252,7 +248,7 @@
 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_expression all of whose dependent_expressions are permitted by this
+conditional_expression all of whose *dependent_*expressions are permitted by this
 rule}:
 
 
@@ -325,13 +321,64 @@
 a required parenthesis, syntax correction would either identify the required
 parenthesis or the expression as missing, showing the correct point of the
 error.
+
+---
+
+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
+changes:
+
+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})
+by:
+   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})];
+by:
+    pragma_argument_association_list ::=
+     (pragma_argument_association {, pragma_argument_association})
+      | (conditional_expression)
 
-[Editor's note: I tried the syntax changes recommended by Steve (explained in
-the Implementation Note in 4.4) in the grammar generator used by Janus/Ada, and
-they appeared to work without ambiguity. I didn't test the overall effect on
-error correction, but at least the rules can be enforced syntactically. That's
-important, because examples like the above will get an error at the "if", not
-some later point.]
+    pragma ::= Pragma identifier [pragma_argument_association_list] ;
 
 ---
 
@@ -412,8 +459,7 @@
     statically moot
     moot
 
-Each reviewer had a favorite, the author chose his but there is nothing
-resembling a consensus.
+The term choosen seems OK, but none are that great.
 
 ----