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

--- ai05s/ai05-0153-1.txt	2009/10/17 03:46:26	1.2
+++ ai05s/ai05-0153-1.txt	2009/11/04 06:26:38	1.3
@@ -1,4 +1,4 @@
-!standard  3.2.2(2)                                   09-05-27    AI05-0153-1/01
+!standard  3.2.2(2)                                   09-10-26    AI05-0153-1/03
 !class Amendment 09-05-27
 !status work item 09-05-27
 !status received 09-05-27
@@ -51,23 +51,50 @@
 I'll leave the formal wording of this to Tucker's proposal. No
 sense in beating my head on a wall to figure this out!]
 
+Most likely, the formal proposal for clauses will require an associated
+operational attribute. In this case that would be S'Predicate, a
+function with a parameter of type S'Base returning Boolean. The
+definition of that attribute is not currently shown here.
+
+The actual predicate is the given expression anded with the predicate
+(if any) of the parent subtype. (The predicate of any subtype that
+does not have one can be assumed to be the boolean literal True.)
+
 [Editor's note: The predicate has no effect on the static or
 dynamic semantics of the subtype indication except as noted here.]
 
+Modify 3.4(18-22/2):
+
+Informally, the predicate of the corresponding subtype is that of the
+subtype of the parent/progenitor type anded with the predicate of the
+derived type.
+
+AARM Reason: If a subprogram has parameter(s) whose subtype(s) have 
+defined predicate(s), the generated code of subprogram body may depend on
+those predicates being checked. (A compile could assume that they had been
+checked at the point of a call.) If the predicates did not compose, a call
+of the derived subprogram might not actually check the predicates, and that
+would cause big trouble.
+
 Modify 4.5.2(29):
 
-The tested type is scalar, and the value of the simple_expression belongs to the given range, or the range of the named subtype {and
+The tested type is scalar, and the value of the simple_expression belongs
+to the given range, or the range of the named subtype {and
 any predicate of the named subtype evaluates to True}; or 
 
+AARM Ramification: If S has a predicate, S'First in S may evaluate to False.
+Similarly for S'Last.
+
 Modify 4.5.2(30/2):
 
-The tested type is not scalar, and the value of the simple_expression satisfies any constraints of the named subtype,
-{any predicate of the named subtype evaluated to True,} and:
+The tested type is not scalar, and the value of the simple_expression satisfies
+any constraints of the named subtype, {any predicate of the named subtype
+evaluated to True,} and:
 
 Add at the end of 4.6(51/2):
 
-If the target subtype has a predicate, then a check is made that applying
-the predicate to the value yields True.
+If the target subtype has a predicate, the predicate is applied to the value
+and Assertions.Predicate_Error is raised if the result is False.
 
 Modify 4.9.1(2/2):
 
@@ -76,6 +103,10 @@
 come from the same predicate_clause, }and, for access subtypes, either both
 or neither exclude null. ...
 
+Add after 11.4.2(13/2):
+
+Predicate_Error : exception; -- See 4.6
+
 
 !discussion
 
@@ -102,11 +133,12 @@
      subtype Even is Integer range 1 .. 10 when Predicate => Even mod 2 = 0;
      type Evens is array (Even) of Boolean; -- 5 or 10 elements?
      Obj : Evens;
-     Obj(1) := False; -- Raises Constraint_Error.
+     Obj(1) := False; -- Raises Predicate_Error.
 
 Type Evens has length 10. Evens'range goes from 1 .. 10. However, attempting
-to index component 1 will raise Constraint_Error. This is a bit annoying,
-but it again is similar to the behavior of null exclusions:
+to index component 1 will raise Predicate_Error. (That's because 1 will be converted
+to subtype Even, as noted in 4.1.1(7), and that will trigger a predicate check.)
+This is a bit annoying, but it again is similar to the behavior of null exclusions:
 
      type Acc_Int is not null access Integer;
      Ptr : Acc_Int; -- Raises Constraint_Error
@@ -149,9 +181,10 @@
 ---
 
 The exception "Constraint_Error" seems wrong for something that is not a
-constraint. With a bit more work, we could define "Predicate_Error" in
-Ada.Assertions and define that to be raised on predicate failures. I didn't
-do that as I was keeping this proposal as simple as possible.
+constraint. Therefore, failed predicates raise Predicate_Error. This seems
+necessary in order to avoid confusing constraint checks (which generally can
+be assumed to remain True after the first check) with predicate checks (which
+generally cannot be assumed to be remain True).
 
 ---