CVS difference for 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
@@ -48,7 +48,8 @@
Added some proposal wording, and put in the missing !wording.
Changed "blocking restriction expression" to "nonblocking expression" as
+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
[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
* 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:
@@ -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
[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