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

--- ai05s/ai05-0147-1.txt	2009/11/04 06:24:24	1.5
+++ ai05s/ai05-0147-1.txt	2010/01/09 01:31:29	1.6
@@ -1,4 +1,4 @@
-!standard 4.4 (07)                                09-10-28  AI05-0147-1/04
+!standard 4.4 (07)                                10-01-07  AI05-0147-1/05
 !standard 4.5.7 (0)
 !standard 4.7(2)
 !standard 4.7(3)
@@ -158,36 +158,48 @@
 * A conditional_expression all of whose conditions and dependent_expressions are
   static expressions;
 
-Split 4.9(33), replacing it by the following:
+Replace 4.9(33) by:
 
-A static expression is evaluated at compile time except when:
- * it is part of the right operand of a static short-circuit control form whose value
-   is determined by its left operand;
- * it is part of a condition of some part of a conditional_expression, and at
-   least one condition of a preceeding part of the conditional_expression has the
-   value True; or
- * it is part of the dependent_expression of some part of a
-   conditional_expression, and the associated condition evaluates to False; or
- * it is part of the dependent_expression of some part of a
-   conditional_expression, and at least one condition of a preceeding part of
-   the conditional_expression has the value True.
-
-AARM Reason: We need the last bullet so that only a single dependent_expression is
-evaluated if there is more than one condition that evaluates to True.
-End AARM Reason.
+An expression is *statically unevaluated* if it is part of:
 
-The compile-time evaluation of a static expression is performed exactly, without
-performing Overflow_Checks. For a static expression that is evaluated:
+* the right operand of a static short-circuit control form whose
+  value is determined by its left operand; or
 
-[Editor's note: Adam Beneschan suggested in AC-0171 to add another cases to this
-list - an aggregate others clause known to denote zero elements:
+* 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
+  where the condition corresponding to at least one preceding
+  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.
+
+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)
+legal if N and Min are static and N = 0.
+End AARM Notes
+
+A static expression is evaluated at compile time except when it is
+statically unevaluated. The compile-time evaluation of a static expression
+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 part of the expression of an array_component_association whose
+  * 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 rewrite of this paragraph would make it easy to add here if desired.]
+the introduction of the "statically unevaluated" term would make it easy to add
+here if desired.]
 
 Delete 5.3(3-4) [they were moved to 4.5.7]
 
@@ -204,27 +216,9 @@
 
 ** TBD: The name resolution rule needs to be replaced by one Tucker proposed (the
 last one preferably). That's in mail that hasn't been filed yet.
-
-** TBD: The static rule is completely wrong, according to Adam. It needs to
-be completely replaced.
-
-Adam would like the static expression evaluation rules to
-apply to *all* conditional expressions that have a static condition.
-He points out that cases like that can't happen in short circuit expressions.
-His main point is that if the unevaluated subexpression is static, it
-could make the entire expression illegal. For example:
-
-    (if N = 0 then Some_Function else 10000 / N)
-
-If N is statically zero, this is still not a static expression. With the
-proposed rules, a compiler is required to evaluate the else part
-statically, triggering 4.9(33) and making the expression illegal.
-Argubly, that's OK (the function call here is suspicious). We need
-to decide what to do.
 ** end TBD.
 
 
-
 !discussion
 
 The syntax of Ada requires that we require some sort of surrounding syntax to
@@ -305,7 +299,9 @@
 Conditional_Expressions are static if all of their conditions and expressions
 are static. But expressions that are not used are not evaluated (and thus the
 program is not illegal if one of those expressions would raise an exception).
-This is similar to the rules for short circuit operations.
+Note that this latter rule applies even to non-static expressions if the
+controlling condition is static. This is similar to the rules for short circuit
+operations.
 
 This means that:
 
@@ -314,8 +310,28 @@
 but
 
 (if False then Some_Function_Call / 0 else 123) is not static.
+
+Note that while (if N = 0 then Some_Function_Call else 10_000 / N)
+is not static even if N is static, the expression is alway legal. That's
+because the else expression is not evaluated if N is 0 (it would be illegal
+if it was).
+
+---
+
+There is no obvious term for the concept defined as "statically unevaluated" above.
+Here are some of the many choices considered:
+    statically unselected
+    statically unevaluated
+    statically unevaluable
+    statically ineffective
+    statically unreachable
+    statically irrelevant
+    statically dead
+    statically moot
+    moot
 
-[Editor's note: Sorry, Steve. ;-)]
+Each reviewer had a favorite, the author chose his but there is nothing resembling
+a consensus.
 
 !examples
 
@@ -2206,6 +2222,33 @@
 up, which has to be read backwards.
 
 At least we alleviate this for PPC's and that's very helpful.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, March  2, 2009  3:21 AM
+
+I've been watching this discussion, and I too dislike "implies". To me, "A implies B"
+means "if A is true, I know that B is true", while in the context of preconditions,
+it means "if A is true, B should be true". Quite different.
+
+In fact, the equivalent of:
+
+pragma precondition (A implies B) should be:
+
+if A then pragma precondition (B) end if; (which is obviously not Ada).
+
+So, why not add an optionnal "when" to the pragma?
+   pragma Precondition(subprogram_local_name,
+     [Check =>] boolean_expression
+     [, When => boolean_expression]
+     [, [Message =>] string_expression]);
+
+Note 1: the proposed syntax requires named association for the "when".
+To be discussed
+
+Note 2: This proposal makes more important the issue of having multiple preconditions.
+I don't think there is a problem, but it has to be addressed anyway.
 
 ****************************************************************