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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0153-3.txt

--- ai05s/ai05-0153-3.txt	2010/10/26 02:39:17	1.1
+++ ai05s/ai05-0153-3.txt	2011/01/25 07:18:09	1.2
@@ -1,4 +1,4 @@
-!standard  3.2.4(0)                                10-10-08    AI05-0153-3/01
+!standard  3.2.4(0)                                11-01-23    AI05-0153-3/02
 !class Amendment 09-05-27
 !status work item 09-05-27
 !status received 09-05-27
@@ -16,10 +16,10 @@
 In many ways, predicates are similar to, but more general than,
 constraints.
 
-If a predicate obeys certain restrictions, the subtype is considered
-static, and can therefore be used as a choice in case statements
-and the like. 'for' loops are also defined over static subtypes
-with predicates.
+There are two predicate aspects: Static_Predicate and Dynamic_Predicate.
+Static_Predicates must obey certain restrictions, and the subtype can be
+static, so it be used as a choice in case statements and the like.
+'for' loops are also defined over subtypes with static predicates.
 
 !problem
 
@@ -27,7 +27,7 @@
 object (including formal parameters). But the constraints that can
 be expressed are limited.
 
-For instance, it isn't possible to specify that a record type may
+For instance, it isn't possible to specify that a record subtype may
 have any of several discriminant values -- for discriminants we can
 only specify a single value or allow all discriminants. Similarly,
 it isn't possible for a subtype to define a noncontiguous subset of
@@ -37,23 +37,30 @@
 
 !proposal
 
-We define a new aspect "Predicate", which takes a condition (i.e. a
-BOOLEAN_expression). The condition can use the defining_identifier of the
-subtype to mean the "current instance" of the subtype (that is, the object to
-test the predicate against), as defined in AI05-0183-1.
-For example:
+We define two new aspect predicate aspects, "Static_Predicate" and
+"Dynamic_Predicate", which take a condition (i.e. a BOOLEAN_expression). The
+condition can use the defining_identifier of the subtype to mean the "current
+instance" of the subtype (that is, the object to test the predicate against),
+as defined in AI05-0183-1.
+
+The difference between Static_Predicate and Dynamic_Predicate is that in the
+former case, the expression is restricted to certain sort-of-static forms,
+which allows such subtypes to be used in situations requiring static subtypes,
+such as in case statements.
+
+Example:
 
     type T is ...;
     function Is_Good(X: T) return Boolean;
     subtype Good_T is T with
-        Predicate => Is_Good(Good_T);
+        Dynamic_Predicate => Is_Good(Good_T);
 
 Good_T conceptually represents the subset of values of type T for
 which Is_Good returns True.
 
-A Predicate may be given on a subtype_declaration,
+A predicate may be given on a subtype_declaration,
 in which case it applies to that subtype.
-A Predicate may also be given on a type_declaration,
+A predicate may also be given on a type_declaration,
 in which case it applies to the first subtype.
 
 The predicate is checked at certain places, such as assignment
@@ -64,23 +71,23 @@
 be False if the predicate of S is False for X, and (for scalars) "X'Valid" will
 be False if the predicate of S is False for X,
 
-The base subtype always has the Predicate "True".
+The base subtype always has the predicate "True".
 Thus, the 'Base attribute may be used to
 remove the predicate; S'Base means "S without any
 constraint or predicate". (Note that 'Base is allowed
 only for scalars. There is no "remove the predicate"
 feature for nonscalars.)
 
-Scalar subtypes with user-defined Predicates cannot be used in cases
+Scalar subtypes with user-defined predicates cannot be used in cases
 that would make sense only for contiguous subranges -- 'First
 is illegal, use as an array index subtype is illegal, and so on.
 Thus, we avoid anomalies like "S'First in S" being False.
 
-Certain subtypes with Predicates are defined to be static.
+Certain subtypes with Static_Predicates are defined to be static.
 For example,
 
     subtype Letter is Character with
-        Predicate => Letter in 'A'..'Z' | 'a'..'z';
+        Static_Predicate => Letter in 'A'..'Z' | 'a'..'z';
 
 Letter is a static subtype.  (Actually, it should probably include
 things like '' -- this is just an example!)
@@ -124,48 +131,63 @@
 
 3.2.4 Subtype Predicates
 
-The language-defined aspect Predicate is defined for subtypes.
+The language-defined "predicate aspects" Static_Predicate and Dynamic_Predicate
+may be used to define properties of subtypes. A "predicate clause" is an aspect
+clause specifying one of the two predicate aspects.
 
 
                              Name Resolution Rules
+
+The expected type for a predicate aspect expression is any boolean type.
+
+
+                               Static Semantics
+
+A predicate clause may be given on a type_declaration or a subtype_declaration,
+and applies to the declared subtype. In addition, predicate clauses apply to
+certain other subtypes:
 
-The expected type for a Predicate expression is any boolean type.
+    - For a (first) subtype defined by a derived type
+      declaration, the predicates of the parent subtype and the
+      progenitor subtypes apply.
 
+    - For a subtype created by a subtype_indication, the
+      predicate of the subtype denoted by the subtype_mark
+      applies.
 
+The "predicate" of a subtype consists of all predicate clauses that apply,
+and-ed together; if no predicate clauses apply, the predicate is True
+Redundant[(in particular, the predicate of a base subtype is True)].
+
                                Legality Rules
 
-A Predicate may be specified on a type_declaration or a subtype_declaration; if
-none is given, an implicit "with Predicate => True" is assumed.
-The predicate of a subtype is defined as follows:
+The expression of a Static_Predicate clause shall be "predicate-static";
+that is, one of the following:
 
-    - For a (first) subtype defined by a derived type declaration, the
-      specified Predicate, and-ed with the predicate of the parent subtype,
-      and-ed with the predicates of the progenitor subtypes.
+    - a static expression that does not raise any exception;
 
-    - For a (first) subtype defined by a non-derived type declaration,
-      the specified Predicate.
+    - a membership test whose left-hand side is the current instance,
+      and whose right-hand side is static;
+[Author's Question: Does that allow "S in (Foo | Bar | Baz)"?]
 
-    - For a subtype created by a subtype_declaration, the specified Predicate,
-      and-ed with the predicate of the subtype denoted by the subtype_mark.
+    - a call to a predefined equality or ordering operator, where one operand
+      is the current instance, and the other is a static expression;
 
-    - For a subtype created by a subtype_indication that is not that of
-      a subtype_declaration, the predicate of the subtype denoted by the
-      subtype_mark.
+    - a call to a predefined boolean logical operator, where both operands
+      are predicate-static; or
 
-    - For a base subtype, True.
+    - a parenthesized predicate-static expression.
 
 An index subtype, discrete_range of an index_constraint or slice, or a
 discrete_subtype_definition of a constrained_array_definition,
 entry_declaration, or entry_index_specification shall not denote a
-subtype with a user-specified predicate.
+subtype to which predicate clauses apply.
 
-The discrete_subtype_definition of a loop_parameter_specification shall not
-denote a subtype with a user-specified predicate, unless the subtype is
-static.
+The prefix of an attribute_reference whose attribute_designator is First, Last,
+or Range shall not denote a subtype to which predicate clauses apply.
 
-The prefix of an attribute_reference shall not denote a subtype with a
-user-specified predicate if the attribute_designator is First, Last,
-or Range.
+The discrete_subtype_definition of a loop_parameter_specification shall not
+denote a subtype to which Dynamic_Predicate clauses apply.
 
 
                                Dynamic Semantics
@@ -207,12 +229,14 @@
 predicate was True.
 
 
-NOTE: A Predicate does not cause a subtype to be considered "constrained".
+NOTE: A predicate clause does not cause a subtype to be considered
+"constrained".
 
-NOTE: A Predicate is not necessarily True for all objects of the subtype at all
+NOTE: A predicate is not necessarily True for all objects of the subtype at all
 times. Predicates are checked as specified above, but can become False at other
-times. For example, the Predicate of a record is not checked when a component is
-modified.
+times. For example, the predicate of a record is not checked when a component
+is modified. Similarly to constraints, predicates can be False for
+uninitialized variables and other invalid values.
 
 [End of 3.2.4.]
 
@@ -247,8 +271,7 @@
       each non-others discrete_choice shall cover only values in that subtype
       {that satisfy the predicate},
       and each value of that subtype {that satisfies the predicate}
-      shall be covered by some discrete_-
-      choice [(either explicitly or by others)];
+      shall be covered by some discrete_choice [(either explicitly or by others)];
 
 Modify 4.5.2(29) so membership tests take the predicate into account:
 
@@ -275,39 +298,18 @@
 If the Assertion_Policy in effect is Check, the predicate of the target subtype
 is applied to the value and Assertions.Assertion_Error is raised if the result
 is False.
-
-Add to the end of 4.9(26/2), so subtypes with predicates of certain
-forms are static:
-
-    Also, a subtype is static only if the predicate is predicate-static.
 
-Add new paragraphs after 4.9(32), to define the term "predicate-static"
-used above in 4.9(26/2):
-
-An expression within a predicate is "predicate-static"
-if it is one of the following:
-
-    - a static expression that does not raise any exception;
-
-    - a membership test whose left-hand side is the current instance,
-      and whose right-hand side is static;
+Add to the end of 4.9(26/2), so subtypes with Static_Predicates can be static,
+but those with Dynamic_Predicate are not:
 
-    - a call to predefined equality or ordering operator, where one operand is
-      the current instance, and the other is a static expression;
+    Also, a subtype is not static if any Dynamic_Predicate clauses apply to it.
 
-    - a call to a predefined boolean logical operator, where both operands
-      are predicate-static; or
-
-    - a parenthesized predicate-static expression.
-
 Modify 4.9.1(2/2), so static matching takes predicates into account:
 
   A subtype statically matches another subtype of the same type if they have
-  statically matching constraints, {all predicate_clauses that apply to them come
-  from the same declarations, }and, for access subtypes, either both or
+  statically matching constraints, {all predicate clauses that apply to them
+  come from the same declarations, }and, for access subtypes, either both or
   neither exclude null. ...
-  [???Should we allow matching for predicates that happen to have all
-  the same values, in the static case?  I think not.]
 
 Modify 4.9.1(4/3), so "statically compatible" takes predicates into account:
 
@@ -323,6 +325,7 @@
   statically compatible with the second only if both subtypes are static, and
   every value that obeys the predicate of the first obeys the predicate of the
   second.}
+[Author's question: Is that reasonable to implement?]
 
 Modify 5.4(7/3), so the full coverage rules for case statements
 take predicates into account:
@@ -361,10 +364,10 @@
 contiguous range. We could relax this somewhat.
 For example, we could allow 'First in the following cases:
 
-    Predicate => True -- which is what you get by default
-    Predicate => 1 > 0 -- static expression with value True
-    Predicate => Cur_Inst in 1..10 -- contiguous range
-    Predicate => Cur_Inst >= 0 -- contiguous range 0..'Base'Last
+    Static_Predicate => True -- which is what you get by default
+    Static_Predicate => 1 > 0 -- static expression with value True
+    Static_Predicate => Cur_Inst in 1..10 -- contiguous range
+    Static_Predicate => Cur_Inst >= 0 -- contiguous range 0..'Base'Last
 
 However, it seems simplest to forbid 'First if there is
 any user-defined predicate.
@@ -398,20 +401,19 @@
 
 This means that "S'(X) in S" could be False if Assertion_Policy is Ignore.
 This is similar to suppressing checks (strange things can happen), but
-far milder, because suppressing checks can cause erroneous behavior,
+milder, because suppressing checks can cause erroneous behavior,
 whereas here, we get True, or False, or Constraint_Error.
 
 ---
 
 Static Predicated Subtypes.
 
-The following operations are allowed in predicate-static expressions:
+The following operations are allowed in Static_Predicate expressions:
 "=", "/=", "<", ">", "<=" ">=", "and", "or", "xor", "not", "in", "not in".
 The following are not: "and then", "or else", "mod", etc -- except that
 these are of course allowed in fully-static subexpressions (i.e. not
 involving the current instance). E.g., "X mod 2" is allowed if X is
-a static constant, but if X is the current instance, then the subtype
-is not static.
+a static constant, but not if X is the current instance.
 
 The purpose of defining some subtypes with user-defined predicates to be static
 is to allow those subtypes in places where the language provides full coverage
@@ -425,11 +427,15 @@
 'A'..'Z' | 'a'..'z'.  We now allow:
 
     subtype Letter is Character with
-        Predicate => Letter in 'A'..'Z' | 'a'..'z';
+        Static_Predicate => Letter in 'A'..'Z' | 'a'..'z';
 
     case Current_Char is
         when Letter => ... -- Allowed by this AI.
 
+    Table : constant array (Character) of Boolean :=
+        (Letter => True, -- Allowed by this AI.
+         others => False);
+
 Every predicate-static expression necessarily has the property that if you plug
 in a static expression in place of every occurrence of the current instance,
 you get a static expression. However, not every expression with this property
@@ -437,26 +443,27 @@
 "Cur_Inst mod 2 = 0" is not, even though both have the above plug-in
 property. The idea is that the set of values for which a predicate-static
 expression is True should be representable as a sequence of static subranges
-whose size is rougly proportional to the size of the relevant source text.  For
+whose size is roughly proportional to the size of the relevant source text.  For
 example:
 
     subtype Even is Natural with
-        Predicate => Cur_Inst mod 2 = 0; -- not predicate-static!
+        Static_Predicate => Cur_Inst mod 2 = 0; -- Illegal!
 
 doesn't qualify, because the the subrange sequence would be
 something like 0..0, 2..2, 4..4, ... 2**31-2..2**31-2, which is
 enormous. We expect implementations to actually form such
 subrange sequences at compile time, which is unreasonable in
 the "mod 2" case. "Cur_Inst > 2", on the other hand, can be
-represented as "3..2**31-1".
+represented as "3..2**31-1". The above would be legal if we
+said Dynamic_Predicate.
 
 Note that the definition of static subtypes allows predicates
 coming from other subtypes:
 
     subtype S1 is Natural with
-        Predicate => S1 < 100 or S1 > 1000;
+        Static_Predicate => S1 < 100 or S1 > 1000;
     subtype S2 is S1 with
-        Predicate => S2 <= 50_000;
+        Static_Predicate => S2 <= 50_000;
 
 S1 is a static subtype, with the subrange sequence 0..99, 1001..Natural'Last.
 S2 is also static, with the subrange sequence 0..99, 1001..50_000.
@@ -479,12 +486,15 @@
 reason is to ensure (without knowing the value of the current instance) that
 predicate-static expressions cannot raise exceptions.
 
-We considered using a different name (perhaps Set_Predicate or
-Static_Predicate) for the static case. We also considered
-using a completely different syntax for the static case -- that's
-essentially the AI05-0153-2 version of this AI).  One problem is that if
-you change a static predicate to a nonstatic one, faraway parts of your
-program can become illegal.  However:
+----------------
+
+An earlier version of this AI proposed a single Predicate aspect, which could
+allow static subtypes or not, depending on whether the expression happened to
+be predicate-static. We decided to split it into two aspects, Static_Predicate
+and Dynamic_Predicate, because otherwise, if you change a static predicate to a
+nonstatic one, faraway parts of your program can become illegal.
+
+The following arguments against the split were rejected:
 
     - They won't change their run-time behavior, just become illegal.
 
@@ -526,8 +536,9 @@
        allow actuals with and without predicates. Without this new syntax,
        actuals would not be allowed to have predicates. We would need to think
        about which language-defined generics should have "Predicate => <>"
-       added. This seems like unnecessary complexity; the Program_Error
-       solution seems sufficient.
+       added. This seems like unnecessary complexity, especially now that
+       Predicate has been split into Static_Predicate and Dynamic_Predicate;
+       the Program_Error solution seems sufficient.
 
     4. The predicate of the actual is ignored in the instance. This seems
        like a bad idea for obvious reasons.
@@ -536,8 +547,8 @@
 
 'for' loops.
 
-We allow "for X in S loop" if S has a user-defined Predicate,
-but only if S is static. It means the same as:
+We allow "for X in S loop" if S has a Static_Predicate,
+but not if it has a Dynamic_Predicate. It means the same as:
 
     for X in S'Base loop
         if X in S then -- query the predicate
@@ -579,7 +590,7 @@
 In some cases, the compiler might unroll the loop.
 For example:
 
-    subtype RGB is Color with Predicate => RGB in Red | Green | Blue;
+    subtype RGB is Color with Static_Predicate => RGB in Red | Green | Blue;
     for X in RGB loop
         Do_Something(X);
     end loop;
@@ -647,7 +658,7 @@
 For example:
 
     type String1 is new String with
-        Predicate => String1'First = 1;
+        Dynamic_Predicate => String1'First = 1;
 
 The compiler can deduce (if the Assertion_Policy is Check) that all objects of
 type String1 have 'First = 1, and optimize accordingly.  It could avoid storing
@@ -658,7 +669,7 @@
    type Rec is record
        A : Natural;
    end record;
-   subtype Decimal_Rec is Rec with Predicate => Rec.A mod 10 = 0;
+   subtype Decimal_Rec is Rec with Dynamic_Predicate => Rec.A mod 10 = 0;
 
    Obj : Decimal_Rec := (A => 10); -- (1)
 
@@ -708,17 +719,17 @@
 Examples:
 
     subtype S is Integer range 1..10 with
-        Predicate => ...;
+        Static_Predicate => ...;
     X: S; -- neither constraint nor predicate is checked
 
-The idea is that X will be initialized later, and the range at
+The idea is that X will be initialized later, and the range and
 predicate will be checked at that time. It makes no sense to
 check the predicate on the declaration of X, since X will have
 some arbitrary junk (possibly invalid) value.
 
     type T is access all String;
     subtype S is T with
-        Predicate => S.all'First = 1;
+        Dynamic_Predicate => S.all'First = 1;
     X: S; -- predicate is not checked
     Y: S := null; -- raises an exception
 
@@ -740,7 +751,7 @@
             Inner: Inner_Record;
         end record;
     subtype S is Outer_Record with
-        Predicate => ...;
+        Dynamic_Predicate => ...;
     X: S; -- predicate IS checked
 
 But if we remove the explicit defaults for A and B,
@@ -781,11 +792,11 @@
 Note that overlapping subsets are allowed in the static case:
 
     subtype S1 is Integer with
-        Predicate => S1 in 1..10;
+        Static_Predicate => S1 in 1..10;
     subtype S2 is Integer with
-        Predicate => S2 in 4..20;
+        Static_Predicate => S2 in 4..20;
     subtype S3 is Integer with
-        Predicate => S3 in S1 | S2; -- overlapping; same as 1..20
+        Static_Predicate => S3 in S1 | S2; -- overlapping; same as 1..20
 
     case ... is
         when S3 => -- OK
@@ -824,9 +835,9 @@
     type Symbol_Ptr is access all Symbol_Record;
 
     subtype Type_Symbol_Ptr is not null Symbol_Ptr with
-       Predicate => Type_Symbol_Ptr.Entity = A_Type;
+       Dynamic_Predicate => Type_Symbol_Ptr.Entity = A_Type;
     subtype Callable_Symbol_Ptr is not null Symbol_Ptr with
-       Predicate =>
+       Dynamic_Predicate =>
           Callable_Symbol_Ptr.Entity = Proc or
           Callable_Symbol_Ptr.Entity = Func or
           Callable_Symbol_Ptr.Entity = An_Entry;
@@ -851,7 +862,8 @@
 size.
 
 Ada measures sizes in bits, but it's sometimes necessary to measure in storage
-units. "Predicate => Blah mod System.Storage_Unit = 0" might come in handy.
+units. "Dynamic_Predicate => Blah mod System.Storage_Unit = 0" might come in
+handy.
 
 A Sort function produces an array (or other sequence) of subtype
 Sorted_Sequence. Binary_Search takes a parameter of that subtype. Very useful
@@ -877,6 +889,565 @@
 
 !appendix
 
+From: Jean-Pierre Rosen
+Sent: Thursday, December 23, 2010  10:01 AM
+
+[Part of a message mostly about the minutes of meeting #42 - Editor]
+
+- From AI05-0153-3(legality rules)
+
+"An index subtype [...] shall not denote a subtype with a
+user-specified predicate."
+The two following paragraphs also refer to user-specified predicate.
+
+This seems to be too narrow. Consider:
+subtype S1 is Integer with Predicate S1 mod 2 = 0; subtype S2 is S1;
+
+Is S2 a subtype with a user specified predicate? Hopefully
+yes, but the formulation is not clear. The definition of a
+predicate of a subtype implies that /part/ of a subtype
+predicate can be user-specified.
+Suggestion:
+"... whose predicate includes parts that are user specified".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, January 23, 2011  5:25 PM
+
+New version of AI05-0153-3, Subtype predicates. [This is version /02 of
+this AI. - Editor]
+The big change is to split the Predicate aspect in two:
+Static_Predicate and Dynamic_Predicate.
+
+As you all know, I really HATE this "compromise".
+It will certainly enhance Ada's well-deserved reputation for being overly
+complicated!  :-(
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 23, 2011  5:44 PM
+
+> The big change is to split the Predicate aspect in two:
+> Static_Predicate and Dynamic_Predicate.
+>
+> As you all know, I really HATE this "compromise".
+> It will certainly enhance Ada's well-deserved reputation for being
+> overly complicated!  :-(
+
+I dislike it too! GNAT implements this, but under protest :-) and we still have
+the simple Predicate aspect that encompasses both together, and intend to
+maintain that implementation, so in practice I suspect people using GNAT will
+likely use that rather than the split ones.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, January 24, 2011  6:24 AM
+
+Having missed the last meeting, I hadn't realised how messy these predicates
+were going. And the dynamic ones sound really dodgy. Why don't we just get rid
+of the dynamic version. Surely the static version is what people will find most
+valueable. This just adds to the feeling that Ada is just as dodgy as other
+languages. Yuk. I feel as if I am going to have to write a rationale that I just
+don't believe in.
+
+PS It is most unlikely that I will get to the Florida meeting. Although
+improved, I am still not fully OK. (I haven't been fully OK for years but I am
+sure you know what I mean!)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  7:02 AM
+
+I think the dynamic predicates are useful, something like
+
+    subtype X is Integer with
+      Predicate => Is_Prime (X),
+      Default_Value => 1;
+
+makes good sense to me!
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, January 24, 2011  6:57 AM
+
+Having thought about it over lunch, I am changing my mind.
+
+Since pre and postconditions can call any old stuff and so are as watertight as
+a colander, the subtype predicates might as well be the same. So get rid of the
+static ones.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  7:12 AM
+
+Well you need the special capabilities of static ones, to use them in membership
+tests and case statements. This is the capability that provides non-contiguous
+enumeration types, which to me is *the* most important capability.
+
+   type Colors is (Red, Blue, Yellow, Green, .....)
+
+   subtype RBG is Colors with
+     Predicate => RBG in Red | Blue | Green;
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  7:48 AM
+
+> Having thought about it over lunch, I am changing my mind.
+
+Hey, I see your health really IS improving today.  Good!
+I'm glad your fever dreams regarding predicates have vanished.
+
+> Since pre and postconditions can call any old stuff and so are as
+> watertight as a colander, the subtype predicates might as well be the
+> same. So get rid of the static ones.
+
+Since you missed the last meeting, let me clue you in:
+I strongly advocated having a single Predicate aspect, which can be used in case
+statements and the like only if it obeys certain sort-of-staticness rules. [In
+fact, I was already annoyed that we have predicates, invariants, constraints,
+and null exclusions, all of which are the same thing -- as everybody would see
+if I could get them to remove their Language Lawyer Hats for just a moment!
+Language Lawyer Blindfolds?]
+
+Others were nervous about the colander-like aspects of this aspect.  Giving the
+colander-like ones a different name (Dynamic_Predicate) was a compromise to make
+those people less nervous.  Tucker bullied me incessantly during the meeting,
+until I finally agreed to it.  ;-)
+
+Although Static_Predicate is the more useful of the two, I'm firmly convinced
+that the dynamic ones are necessary. Everybody agrees that we want
+non-contiguous enums. But as soon as you have that, you will certainly want to
+constrain discriminants of that enum type in the same way.
+
+Please don't worry about "dodginess".  Nobody is forcing, or even encouraging,
+anyone to write dodgy predicates.  Just don't do that.
+
+I can give you plenty of non-dodgy examples for your Rat, by the way.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, January 24, 2011  7:52 AM
+
+Why can't the one predicate do both?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  8:17 AM
+
+> Why can't the one predicate do both?   John
+
+Because that will cause Randy and others to "snap", and we won't have this
+extremely useful feature at all.
+
+To understand that point of view, consider this analogy:
+Why can't we have a single feature that does what type conversions do, and also
+does what Unchecked_Conversions do? Well, because one is more dangerous, so it's
+a good idea to have separate syntax.
+
+Consider C:  some casts are extremely dangerous, and others are relatively
+innocuous, and it's hard to tell which is which by reading the code.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 24, 2011  8:17 AM
+
+> New version of AI05-0153-3, Subtype predicates.
+> The big change is to split the Predicate aspect in two:
+> Static_Predicate and Dynamic_Predicate.
+>
+> As you all know, I really HATE this "compromise".
+> It will certainly enhance Ada's well-deserved reputation for being
+> overly complicated!  :-( ...
+
+There was a tremendous amount of discussion which led up to this compromise.
+Unfortunately, reopening such discussions can waste a lot of time, unless there
+is some new information.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  8:29 AM
+
+> There was a tremendous amount of discussion which led up to this
+> compromise.  Unfortunately, reopening such discussions can waste a lot
+> of time, unless there is some new information.
+
+I'm not reopening anything.  I'm just venting my frustration.
 
+John wasn't present for those discussions, so I've tried to bring him up to
+speed.  As far as I'm concerned, the issue is settled.
+
+But I'm not like Robert, who thinks that if lots of smart people believe the
+wrong thing, it must therefore be the right thing.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  8:21 AM
+
+By the way, if I had to choose just one AI for Ada 2012, with all the others
+rejected, subtype predicates would be the one.  It's that useful.
+
+And that usefulness comes from its generality.  It's simply impossible to plug
+all the holes in the colander without severely damaging the feature.  Plugging
+just some holes is pointless.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 24, 2011  8:25 AM
+
+> Why can't the one predicate do both? John
+
+The issue here is maintenance.  With just one aspect, a small change can
+dramatically affect where the subtype can be used, and that might not be
+detected until much later.  If the code where the predicate is specified is
+compiled at one time, and the code where the subtype is used is compiled much
+later, by a different developer, then it could be very painful.
+
 ****************************************************************
 
+From: Bob Duff
+Sent: Monday, January 24, 2011  8:31 AM
+
+An obviously-bogus argument, as I explained at the meeting, and also in the AI.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 24, 2011  8:27 AM
+
+> Because that will cause Randy and others to "snap", and we won't have
+> this extremely useful feature at all.
+
+I think maintenance issues were underlying Randy's concern, as I mentioned in my
+prior response.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  9:00 AM
+
+But don't worry too much, in the forseeable future only GNAT will implement Ada 2012 and there you will have one predicate that does both :-)
+
+> Because that will cause Randy and others to "snap", and we won't have
+> this extremely useful feature at all.
+
+And of course it will be just fine to have coding standards forbidding the use
+of the Predicate aspect in GNAT.
+
+P.S. should we have a restriction
+
+No_Implementation_Aspects
+
+Seems like we should, I think I will implement that in GNAT in any case.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  9:01 AM
+
+> By the way, if I had to choose just one AI for Ada 2012, with all the
+> others rejected, subtype predicates would be the one.  It's that
+> useful.
+>
+> And that usefulness comes from its generality.  It's simply impossible
+> to plug all the holes in the colander without severely damaging the
+> feature.  Plugging just some holes is pointless.
+
+I fully agree!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  9:05 AM
+
+> I think maintenance issues were underlying Randy's concern, as I
+> mentioned in my prior response.
+
+Right, the argument is something like
+
+static predicates: good, easy to maintain, useful etc.
+
+dynamic predicates: bad, hard to maintain, potentially expensive etc.
+
+But if you separate them into two aspects, then I can easily have coding
+standards forbidding or limiting the bad, without affecting the good.
+
+A perfectly reasonable argument, not one I ultimately agree with, but I am happy
+with the AI the way it is separating these, given that I can still implement the
+more general Predicate aspect encompassing them both in GNAT, and furthermore
+this extension does not create problems for those who agree with the argument
+above.
+
+If you find Dynamic_Predicate dangerous and want to restrict its use, then you
+just do the same with Predicate.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  9:07 AM
+
+> But I'm not like Robert, who thinks that if lots of smart people
+> believe the wrong thing, it must therefore be the right thing.
+
+That's not quite the robert philosophy, which goes like this
+
+If you believe that X is correct, but the majority overrules you in a smart
+group of people like the ARG then either
+
+a) you are wrong, and X is not correct
+
+b) you are right, but you are incompetent at presenting your argument
+   sufficiently convincingly.
+
+:-) :-)
+
+In either case, no point in holding on to the minority view point :-)
+
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  9:52 AM
+
+> P.S. should we have a restriction
+>
+> No_Implementation_Aspects
+
+Yes, good idea.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  10:02 AM
+
+By the way, obviously some folks would like to forbid Dynamic_Predicate, so there should be a restriction for that.  Instead of doing it piecemeal, we should do like we did for No_Dependence, and have a general feature for forbidding any aspect.  Somethin
g like:
+
+    pragma Restrictions (No_Aspect => Dynamic_Predicate);
+
+We could have an enum type somewhere that lists all the aspect names.  Or we
+could just allow an "aspect_identifier" there, without involving visibility --
+like pragma arguments.  For aspects that are also attributes or pragmas, the
+restriction should forbid both forms.
+
+I've got no problem with self-imposed or project-imposed restrictions!  If,
+someday, some customer requests No_Evil_Predicates, I expect AdaCore would
+implement it (if we can come up with a coherent definition of "evil").
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 24, 2011  10:19 AM
+
+Or perhaps something like:
+
+   pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate);
+
+to be analogous to "No_Dependence => ...".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, January 24, 2011  10:38 AM
+
+Yes, that's better.  For those aspects that are also attributes, you probably
+want to restrict the specification, but not the query.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 24, 2011  9:29 PM
+
+> Because that will cause Randy and others to "snap", and we won't have
+> this extremely useful feature at all.
+>
+> To understand that point of view, consider this analogy:
+> Why can't we have a single feature that does what type conversions do,
+> and also does what Unchecked_Conversions do?
+> Well, because one is more dangerous, so it's a good idea to have
+> separate syntax.
+>
+> Consider C:  some casts are extremely dangerous, and others are
+> relatively innocuous, and it's hard to tell which is which by reading
+> the code.
+
+I hope it doesn't cause me to "snap" (although you never know... :-).
+
+At the risk of prelonging a discussion that is almost over, let me explain my
+position a bit.
+
+A static predicate, to me, is really a kind of constraint. (I would have
+preferred that it be treated that way, but no need to go there.) In particular,
+all of the properties that scalar constraints have also hold for static
+predicates. That means that, once checked, such a predicate holds for an object
+until it is assigned again. (And presumably, the assignment check will again
+check it, so it will still be in range.) That means that they can be included in
+reasoning about the semantics of a particular object. In addition, you can use
+them the same ways in case statements and loops.
+
+OTOH, a dynamic predicate is really a kind of Assert pragma (automatically
+inserted). Like all assert pragmas, the predicate can only be assumed true at
+the point at which it is checked. (And, unlike an assert pragma, it's harder to
+figure out where those points are.) That means that you have to be very careful
+when including these in reasoning about your program. Moreover, even predicates
+that "look" like they hold for the life of an object might not for composite
+objects (as they are not checked when individual components are changed).
+
+I wouldn't want to claim that dynamic predicates aren't useful, just that they
+need a different approach when thinking about the effect on program semantics.
+And that need is best handled by some sort of differentiation between the two,
+especially for the human readers that need to do program reasoning (which is
+most of them).
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, January 25, 2011  12:38 AM
+
+> And that need is best handled by some sort of differentiation between
+> the two, especially for the human readers that need to do program
+> reasoning (which is most of them).
+            ^^^^^^^^^^^^^^^^^^^^^^^
+Alas, wishful thinking!
+(sorry, couldn't resist)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 25, 2011  12:49 AM
+
+[Specific wording comments here, no political discussion.]
+
+Bob Duff writes:
+...
+> The expression of a Static_Predicate clause shall be
+> "predicate-static"; that is, one of the following:
+>
+>     - a static expression that does not raise any exception;
+>
+>     - a membership test whose left-hand side is the current instance,
+>       and whose right-hand side is static; ???Does that allow "S in
+> (Foo | Bar | Baz)"?
+
+No, because the above isn't syntactally correct :-) (no parens needed). And
+still no even with the parens removed; the right-hand side here is not an
+expression at all, but just a list of choices. It can't be static by itself. You
+probably want to borrow the 4.9(13) wording for memberships:
+
+...and whose membership_choice_list consists only of membership_choices each of which is either a static choice_expression, a static range, or a subtype_mark that denotes range is a static range or whose subtype_mark denotes a static [(scalar or string)] 
subtype;
+
+Probably there is some way to simplify this, but I'll leave that as an exercise
+for the author.
+
+> NOTE: A predicate is not necessarily True for all objects of the
+> subtype at all times. Predicates are checked as specified above, but
+> can become False at other times. For example, the predicate of a
+> record is not checked when a component is modified. Similarly to
+> constraints, predicates can be False for uninitialized variables and
+> other invalid values.
+
+I would have thought that this note would only apply to Dynamic_Predicates. The
+only time it could apply for Static_Predicates is for uninitialized values, and
+that doesn't seem to be worth a note -- it's inclusion in the note mainly seems
+to be to somehow justify making the bogus claim that these are not different in
+how they work. And I don't think it is possible for an non-erroneous program to
+have a Static_Predicate become False for an object for which it previously was
+True. So most of the note seems to imply that Static_Predicates are no better
+than their dynamic brethren, which is baloney. (The last sentence is fine, of
+course I would think it would be a good idea for the *real* difference between
+the kinds of predicates to be explained here, otherwise it might be too
+mysterious. Perhaps something like:
+
+NOTE: A Dynamic_Predicate is not necessarily True for all objects of the subtype
+at all times. Dynamic_Predicates are checked as specified above, but can become
+False at other times. For example, the predicate of a record is not checked when
+a component is modified. In contrast, in the absence of erroneous execution or
+uninitialized variables and other invalid values, a Static_Predicate (like a
+constraint) will remain True all of the time.
+
+[Sorry, didn't realize that there was a political note in the wording when I put
+the "no political discussions" banner at the top.]
+
+...
+> Modify 4.9.1(4/3), so "statically compatible" takes predicates into
+> account:
+>
+>   A constraint is statically compatible with a scalar subtype if it statically
+>   matches the constraint of the subtype, or if both are static and the
+>   constraint is compatible with the subtype.  A constraint is statically
+>   compatible with an access or composite subtype if it statically matches the
+>   constraint of the subtype, or if the subtype is unconstrained.  One subtype
+>   is statically compatible with a second subtype if the constraint of the first
+>   is statically compatible with the second subtype, and in the case of an
+>   access type, if the second subtype excludes null, then so does the first.
+>   {Also, if either subtype has a user-defined predicate, then the first is
+>   statically compatible with the second only if both subtypes are static, and
+>   every value that obeys the predicate of the first obeys the predicate of the
+>   second.}
+>???Is that reasonable to implement?
+
+Since the subtypes are static, this is just a set comparison, and the sets are
+static. So that shouldn't be a problem. It should be possible to turn any
+Static_Predicate (including those with comparison and boolean operators) into a
+set representation, and then a simple compare should give the answer. If you
+couldn't convert to a set, you couldn't test case completeness, so I think it
+has to be doable and you'll have to do it for case statements even if we didn't
+require it here (so doing so here won't add any cost).
+
+> !discussion
+>
+> ???Much of this discussion probably belongs in the AARM!
+
+Well, since AI authors are supposed to propose AARM notes, we know who should
+have done that. :-) I'd certainly appreciate it if you did suggest the notes
+that you think are necessary (and where they should go).
+
+> ----------------
+>
+> An earlier version of this AI proposed a single Predicate aspect,
+> which could allow static subtypes or not, depending on whether the
+> expression happened to be predicate-static. We decided to split it
+> into two aspects, Static_Predicate and Dynamic_Predicate, because
+> otherwise, if you change a static predicate to a nonstatic one,
+> faraway parts of your program can become illegal.
+>
+> The following arguments against the split were rejected:
+>
+>     - They won't change their run-time behavior, just become illegal.
+>
+>     - Changing the VALUES can have the same effect, so different
+>       syntax doesn't really solve the problem.  (E.g. "Cur_Inst
+>       in 1..10" changed to "Cur_Inst in 1..10 | 20".)
+>
+>     - We already have this "problem" for other static things
+>       (changing "subtype S is Integer range 1..10" to
+>       "1..Non_Static" or "1..11" can cause faraway
+>       illegalities).
+>
+>     - Although it might be mildly useful, we don't say
+>       "C: static constant Integer := ...", so why should we
+>       do so for predicates?
+
+It would be nice to say more in *favor* of the split as well; the text seems (to
+me at least) to be biased against the solution we chose. I realize that it is
+asking a lot of you to provide those arguments, as you don't believe in them.
+I'll help you do it if needed.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 24, 2011  9:07 AM
+
+****************************************************************

Questions? Ask the ACAA Technical Agent