CVS difference for ai12s/ai12-0064-2.txt

--- ai12s/ai12-0064-2.txt	2017/02/10 04:34:14	1.10
+++ ai12s/ai12-0064-2.txt	2017/02/10 19:25:55	1.11
@@ -1,4 +1,4 @@
-!standard 9.5(17/3)                                 17-02-09    AI12-0064-2/07
+!standard 9.5(17/3)                                 17-02-10    AI12-0064-2/08
 !standard 9.5.1(8)
 !standard 9.5.1(9)
 !standard 9.5.1(10)
@@ -90,7 +90,7 @@
 of generic units. Outside of any generic, it is required to be static so that
 we can enforce Legality Rules based on an unambigious value. In order to
 follow the model of preconditions, the expression is given a name, the
-"blocking requirement expression". I changed as many uses as possible to use
+"blocking restriction expression". I changed as many uses as possible to use
 this name; it makes more sense than talking about the "value of the
 Nonblocking aspect" when that might be a complex expression.
 
@@ -145,12 +145,12 @@
 
    Nonblocking
 
-       This aspect specifies the blocking requirement for the entity; it shall
-       be specified by an expression, called a *blocking requirement
+       This aspect specifies the blocking restriction for the entity; it shall
+       be specified by an expression, called a *blocking restriction
        expression*. If directly specified, the aspect_definition shall be a
        nonblocking-static expression. The expected type for the expression is
        Boolean. [Redundant: The aspect_definition can be omitted from the
-       specification of this aspect; in that case the blocking requirement
+       specification of this aspect; in that case the blocking restriction
        expression for the entity is the enumeration literal True.]
 
          AARM Proof: 13.1.1 allows omitting the aspect expression for
@@ -171,7 +171,7 @@
        13.1(9.4/5) does not apply to aspect Nonblocking. This is the
        "unless otherwise specified" of that rule.]
 
-       When the blocking requirement expression is static for an entity,
+       When the blocking restriction expression is static for an entity,
        the expression is evaluated to produce a static value for aspect.
        When aspect Nonblocking is statically False for an entity, the entity
        might contain a potentially blocking operation; such an entity *allows
@@ -186,7 +186,7 @@
          contexts it is treated more like a static value than an expression.
 
          AARM Ramification: specifying Nonblocking as False imposes
-         no requirements. Specifying Nonblocking as True imposes
+         no restrictions. Specifying Nonblocking as True imposes
          additional compile-time checks to prevent blocking, but does not
          prevent deadlock. A pragma Detect_Blocking can be used to ensure
          that Program_Error is raised in a deadlock situation.
@@ -200,7 +200,7 @@
        confirming.
 
          AARM Ramification: If replacing Nonblocking attribute references
-         makes the blocking requirement expression of an entity declared within
+         makes the blocking restriction expression of an entity declared within
          a generic instance into a static expression, the value of that
          expression is used to recheck all of the nonblocking Legality Rules
          in a generic specification. For instance, an instance is illegal
@@ -211,7 +211,7 @@
        Nonblocking aspect explicit; while it follows from "normal" generic
        instance processing, it's unusual enough to be worth spelling out.]
 
-       For a (protected or task) entry, the blocking requirement expression is
+       For a (protected or task) entry, the blocking restriction expression is
        the Boolean literal False.
 
          AARM Reason: An entry can be renamed as a procedure, so the value
@@ -223,10 +223,10 @@
          individual rules for these cases, but there were already many
          of them, and this solution avoids the need for extra rules.
 
-       For a predefined operator of an elementary type the blocking requirement
+       For a predefined operator of an elementary type the blocking restriction
        expression is the Boolean literal True. For a predefined operator of a
-       composite type, the blocking requirement expression of the operator is
-       determined by the blocking requirement expression for the type.
+       composite type, the blocking restriction expression of the operator is
+       determined by the blocking restriction expression for the type.
 
           AARM Reason: Predefined operators of elementary types can never
           include any potentially blocking operations, so we want them to
@@ -243,7 +243,7 @@
           have this rule apply to the operators, not the types.
 
           AARM Ramification: It's not possible to specify the blocking
-          requirement expression of a predefined operator; if an operator
+          restriction expression of a predefined operator; if an operator
           is declared in order to do that, it is no longer predefined.
 
        [Redundant: For a full type declaration that has a partial view, the
@@ -263,21 +263,21 @@
           actual parameters of the instance is only necessary when the aspect
           is explicitly specified for the formal type.
 
-       Unless directly specified, for a derived type, the blocking requirement
+       Unless directly specified, for a derived type, the blocking restriction
        expression is that of the parent type.
 
           AARM Discussion: The expressions that can be specified for a derived
           type are limited by a Legality Rule, see below.
 
        Unless directly specified, for any other program unit, type, or formal
-       object, the blocking requirement expression of the entity is determined
-       by the blocking requirement expression for the innermost program unit
+       object, the blocking restriction expression of the entity is determined
+       by the blocking restriction expression for the innermost program unit
        enclosing the entity.
 
           [Editor's note: Formal objects are here since objects don't have
           the aspect in general, only in this specific case.]
 
-       If not specified for a library unit, the blocking requirement expression
+       If not specified for a library unit, the blocking restriction expression
        is the Boolean literal True if the library unit is declared pure and is
        not a generic unit, and the Boolean literal False otherwise.
 
@@ -453,7 +453,7 @@
       blocking in the full view.
 
    Aspect Nonblocking shall be specified for a derived type only if it
-   confirms the blocking requirement expression of the ancestor type or if
+   confirms the blocking restriction expression of the ancestor type or if
    it is specified to have the Boolean literal True.
 
       AARM Reason: Boolean-valued aspects have a similar rule (see 13.1.1),
@@ -488,7 +488,7 @@
 
       AARM Ramification: This applies to both record and array "=".
 
-   In a generic instantiation (after replacement in the blocking requirement
+   In a generic instantiation (after replacement in the blocking restriction
    expressions by values of the actuals as described previously):
 
       * the actual subprogram corresponding to a nonblocking formal
@@ -543,10 +543,10 @@
     checks in P, a call to a subprogram is considered to allow blocking
     unless:
        * the value of its Nonblocking aspect is statically True, or
-       * its blocking requirement expression (that is, Nonblocking aspect)
+       * its blocking restriction expression (that is, Nonblocking aspect)
          conforms exactly to that of P, or conforms to some part of the blocking
-         requirement expression of P that is combined with the remainder of the
-         blocking requirement expression of P by one or more "and" or "and then"
+         restriction expression of P that is combined with the remainder of the
+         blocking restriction expression of P by one or more "and" or "and then"
          operations.
 
       AARM Ramification: That is, if the aspect of the program unit is specified