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

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0064-2.txt

--- ai12s/ai12-0064-2.txt	2017/09/06 01:58:29	1.16
+++ ai12s/ai12-0064-2.txt	2017/09/07 01:38:06	1.17
@@ -1,4 +1,4 @@
-!standard 9.5(17/3)                                 17-09-015    AI12-0064-2/11
+!standard 9.5(17/3)                                 17-09-06    AI12-0064-2/12
 !standard 9.5.1(8)
 !standard 9.5.1(9)
 !standard 9.5.1(10)
@@ -48,7 +48,8 @@
 Added some proposal wording, and put in the missing !wording.
 
 Changed "blocking restriction expression" to "nonblocking expression" as
-requested.
+requested. Changed many occurrences of "nonblocking expression" to
+"Nonblocking aspect" as suggested by Tucker.
 
 Changed "nonblocking-static" expressions to only allow combining with
 "and" and "and then", as requested. Note that I didn't change the wording
@@ -64,10 +65,11 @@
 I'm not giving exact numbers as editing changes the line numbers frequently.]
 
 Changed the "assume-the-best" and "assume-the-worst" rules to apply to
-stand-alone generic specifications and generic bodies as well. Since
-calls to subprograms that allow blocking can occur in the elaboration
-code of generic packages and in the bodies of generic subprograms, we
-need to know when and how to make these checks as well. [This wording can
+stand-alone generic specifications and generic bodies as well as entities
+declared inside of them. (I noted this while describing the AI to the ARG in
+Vienna.) Since calls to subprograms that allow blocking can occur in the
+elaboration code of generic packages and in the bodies of generic subprograms,
+we need to know when and how to make checks on those calls. [This wording can
 be found at approximately lines 600-620 in this AI.]
 
 Minor: The nonblocking expression of a predefined operator of a composite
@@ -76,10 +78,11 @@
 expresses the intent. (Else someone will ask "determined how"?).
 
 Note: We didn't discuss the Open Issue found near line 740; we need to decide
-how many Nonblocking aspects will be added to the Standard. I personally think
-we should write them all as aspects, since Global will have to be written that
-way, having both pragmas and aspects is ugly, and as such no Program Unit
-pragma Nonblocking is needed.]
+how Nonblocking aspects will be added to the Standard library. I personally
+think we should write them all as aspects, since Global will have to be written
+that way, having both pragmas and aspects is ugly, and as such no Program Unit
+pragma Nonblocking is needed. But this needs discussion, as it changes the
+Barnes compromise.]
 
 [Summary of changes for June 2017 meeting: (Note: I kept this for the benefit
 of people who were not at the Vienna meeting.)
@@ -176,10 +179,10 @@
    An expression is *nonblocking-static* if it is one of the following:
       * a static expression;
       * a Nonblocking attribute reference;
-      * a call to a predefined boolean logical operator /and/
-        where each operand is nonblocking-static;
-      * an /and then/ short-circuit control form where both operands
-        are nonblocking-static;
+      * a call to a predefined boolean logical operator /and/ where each
+        operand is nonblocking-static;
+      * an /and then/ short-circuit control form where each operand is
+        nonblocking-static;
       * a parenthesized nonblocking-static expression. 
 
    [Editor's note: This wording is intended to parallel the definition of
@@ -193,9 +196,9 @@
       other nonblocking aspects, but we don't allow anything with a value
       not known at compile-time.
      
-   For a program unit, for a task entry, for
-   a formal package, formal subprogram, formal object of an anonymous
-   access-to-subprogram type, and for a type (including a formal type), the
+   For a program unit, for a task entry, for a formal package, formal
+   subprogram, formal object of an anonymous access-to-subprogram type, 
+   enumeration literal, and for a type (including a formal type), the
    following language-defined operational aspect is defined:
 
    Nonblocking
@@ -232,6 +235,12 @@
        13.1(9.4/5) does not apply to aspect Nonblocking. This is the
        "unless otherwise specified" of that rule.]
 
+         AARM Ramification: The Nonblocking aspect cannot be specified for
+         predefined operators or enumeration literals but we don't need to
+         mention that above. One would have to declare a subprogram in order
+         specify the aspect, but that makes a user-defined subprogram which
+         is itself not a predefined operator or an enumeration literal.
+         
        When the nonblocking expression is static for an entity,
        the expression is evaluated to produce a static value for the aspect.
        When aspect Nonblocking is statically False for an entity, the entity
@@ -255,11 +264,11 @@
        For a generic instantiation and entities declared within such an
        instance, the aspect is determined by the nonblocking
        expression for the corresponding entity of the generic unit, with
-       any Nonblocking attributes of the generic formal parameter replaced
-       by the appropriate expression of the corresponding actual parameters.
-       If the aspect is directly specified for an instance, the specified
-       expression shall be static and have the same value as the nonblocking
-       expression of the instance (after replacement).
+       any Nonblocking attributes of the generic formal parameters replaced
+       by the appropriate nonblocking expression of the corresponding actual
+       parameters. If the aspect is directly specified for an instance, the
+       specified expression shall be static and have the same value as the
+       nonblocking expression of the instance (after replacement).
 
          AARM Reason: We want to allow confirming aspects for instances,
          but nothing else. The Legality Rules of the generic body were
@@ -290,7 +299,7 @@
        to know that the instance is nonblocking without having to look up the
        definition of the generic unit and repeat any substitutions.]
 
-       For a (protected or task) entry, the nonblocking expression is
+       For a (protected or task) entry, the Nonblocking aspect is
        the Boolean literal False.
 
          AARM Reason: An entry can be renamed as a procedure, so the value
@@ -302,29 +311,41 @@
          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 nonblocking 
-       expression is the Boolean literal True. For a predefined operator of a
-       composite type, the nonblocking expression of the operator is
-       the same as the nonblocking expression for the type.
+       For an enumeration literal, the Nonblocking aspect is the Boolean
+       literal True.
 
+         AARM Reason: Enumeration literals can be renamed as functions,
+         and passed to generic formal functions, so we need to defined
+         the value of the aspect so the other rules are meaningful.
+
+       For a predefined operator of an elementary type the Nonblocking 
+       aspect is the Boolean literal True. For a predefined operator of a
+       composite type, the Nonblocking aspect of the operator is
+       the same as the Nonblocking aspect for the type.
+
           AARM Reason: Predefined operators of elementary types can never
           include any potentially blocking operations, so we want them to
           declare that. Record equality can be composed of operations
           including user-defined "=" operators, which might allow blocking.
           Array equality might use some record equality. So we have to
           have the possibility of allowing blocking for them. We don't just
-          copy the nonblocking aspect of the type, as someone could declare
-          an elementary type to allow blocking, but we don't want to have to
-          worry about generic matching, so the operators are handled separately.
-          In addition, aspects of subprograms can be view-specific, while
-          aspects of types cannot be view specific (see 13.1.1); thus in order
-          to handle private types completed by elementary types, we need to
-          have this rule apply to the operators, not the types.
+          copy the Nonblocking aspect of the type in every case, as someone
+          could declare an elementary type to allow blocking, but we don't want
+          to have to worry about generic matching, so the operators of elementary
+          types are handled separately. In addition, aspects of subprograms can
+          be view-specific, while aspects of types cannot be view specific (see
+          13.1.1); thus in order to handle private types completed by
+          elementary types, we need to have this rule apply to the operators,
+          not the types.
 
           AARM Ramification: It's not possible to specify the nonblocking
           expression of a predefined operator; if an operator
           is declared in order to do that, it is no longer predefined.
 
+       For a dereference of an access-to-subprogram type, the Nonblocking
+       aspect of the designated subprogram is that of the access-to-subprogram
+       type.
+
        [Redundant: For a full type declaration that has a partial view, the
        aspect is the same as that of the partial view.]
 
@@ -342,16 +363,15 @@
           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 nonblocking 
-       expression is that of the parent type.
+       Unless directly specified, for a derived type the Nonblocking 
+       aspect 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 nonblocking expression of the entity is determined
-       by the nonblocking expression for the innermost program unit
-       enclosing the entity.
+       object, the Nonblocking aspect of the entity is determined by the
+       Nonblocking aspect 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.]
@@ -426,8 +446,9 @@
      * a delay_statement;
      * an abort_statement;
      * task creation or activation;
-     * an external call on a protected subprogram (or an external requeue)
-       with the same target object as that of the protected action;
+     * during a protected action, an external call on a protected subprogram
+       (or an external requeue) with the same target object as that of the
+       protected action;
 
      AARM Reason: This is really a deadlocking call, rather than a blocking
      call, but we include it in this list for simplicity.
@@ -532,9 +553,8 @@
    unit or declared inside of a generic unit, the aspect_definition shall
    be a static expression.
 
-   If the prefix of a Nonblocking attribute reference denotes a generic unit G
-   or an entity declared within a generic unit G, the reference shall occur
-   within the declarative region of G.
+   If the prefix of a Nonblocking attribute reference denotes a generic unit G,
+   the reference shall occur within the declarative region of G.
 
       AARM Reason: We want the value of Nonblocking attributes to be static
       so long as they occur outside of any generic unit. The Nonblocking
@@ -549,20 +569,32 @@
       AARM Ramification: This rule does not apply to instances of generic
       units and entities declared within them.
 
-   [Editor's note: Visibility takes care of a lot of this rule, and perhaps
-   we can drop the part about "an entity declared withing a generic unit G".
-   I am just taking the certain approach of banning everything we don't want
-   to allow even if it might not be possible, lest Steve find a way.]
+   [Editor's note: We don't need to talk about entities "declared within a
+   generic unit G", as those aren't visible anyway, and thus can't be used
+   as a prefix of an attribute. If someone finds a way to do that, we'll need
+   to add that to this rule.]
 
    The predefined equality operator for a composite type is illegal if it is
-   nonblocking and any primitive or predefined "=" for any component type
-   allows blocking.
+   nonblocking and, for a record type, it is not overridden by a primitive
+   equality operator, and:
+      * for a record type, the parent primitive "=" allows blocking; or
+      * any component that has a record type that has a primitive "=" that
+        allows blocking; or
+      * any component that has a non-record type that has a predefined "="
+        that allows blocking.
 
       AARM Ramification: This applies to both record and array "=".
 
       This check occurs when the equality operator is declared, so this rule
       effectively makes the type illegal if the rule is violated.
       End AARM Ramification.
+
+      AARM Reason: We don't need to check this when the operator is
+      overridden for a record type, as the body of the new definition of
+      equality will enforce the rules, and there is no case where the
+      predefined operator will re-emerge. We do have to check this
+      for array types even if the operator is overridden, as the predefined
+      operator will re-emerge in generics and record equality.
 
    In a generic instantiation (after replacement in the nonblocking 
    expressions by values of the actuals as described previously):

Questions? Ask the ACAA Technical Agent