CVS difference for ai12s/ai12-0064-2.txt
--- ai12s/ai12-0064-2.txt 2017/09/07 01:38:06 1.17
+++ ai12s/ai12-0064-2.txt 2017/11/22 02:58:02 1.18
@@ -1,4 +1,4 @@
-!standard 9.5(17/3) 17-09-06 AI12-0064-2/12
+!standard 9.5(17/3) 17-10-13 AI12-0064-2/13
!standard 9.5.1(8)
!standard 9.5.1(9)
!standard 9.5.1(10)
@@ -352,6 +352,13 @@
AARM Proof: Type aspects are never view-specific; they always have
the same value for all views. This is formally stated in 13.1.
+ For an inherited primitive subprogram, if the subprogram is null
+ or abstract, the subprogram is nonblocking if the corresponding
+ subprogram of any ancestor is nonblocking. If the subprogram is
+ neither null nor abstract, the subprogram is nonblocking if and
+ only if the corresponding subprogram of the parent is
+ nonblocking.
+
Unless directly specified, overridings of dispatching operations
inherit this aspect.
@@ -467,11 +474,12 @@
existing code to a Bounded Error (since the default for Nonblocking
is False, and that has to be the case for compatibility).]
- If a language-defined subprogram allows blocking, then it is a potentially
- blocking operation.
+ If a language-defined subprogram allows blocking, then a call on the
+ subprogram is a potentially blocking operation.
-[Editor's note: This is what remains of 9.5.1(18). The old definition should be
-reflected in the aspect values for language-defined routines.]
+[Editor's note: This is what remains of 9.5.1(18). The old definition should
+be reflected in the aspect values for language-defined routines; see the
+discussion of language-defined units below.]
Legality Rules
@@ -515,7 +523,8 @@
A subprogram shall be nonblocking if it overrides a nonblocking
dispatching operation. An entry shall not implement a nonblocking
- procedure.
+ procedure. If an inherited subprogram allows blocking, then
+ the corresponding subprogram of each ancestor shall allow blocking.
AARM Discussion: Rules elsewhere in the standard (4.6 and 3.10.2)
ensure that access-to-subprogram conversion and the Access attribute
@@ -526,10 +535,10 @@
AARM Ramification: A nonblocking subprogram can override one that
allows blocking, but the reverse is illegal. Thus one can declare
a Finalize subprogram to be nonblocking, even though it overrides a
- routine that allows blocking. (This works as a nonblocking subprogram
- allows a strict subset of the operations allowed in allows blocking
- subprograms, so calling such a subprogram as if it allows blocking
- -- as is necessary in a dispatching call -- is harmless.)
+ routine that allows blocking. (This works because a nonblocking
+ subprogram allows a strict subset of the operations allowed in allows
+ blocking subprograms, so calling such a subprogram as if it allows
+ blocking -- as is necessary in a dispatching call -- is harmless.)
It is illegal to specify aspect Nonblocking for the full view of a type
@@ -770,13 +779,18 @@
Ada code, the stream operations allow blocking. Thus the
stream-oriented attributes must allow blocking as well.
+
Wording for definition of language-defined packages and subprograms is TBD.
These are just appropriate aspect clauses, and in a few cases, the deletion
of the English text that says something is potentially blocking.
+
+If a language-defined package needs to add Nonblocking, any pragma will
+also be changed to the aspect form at the same time. [Author's note: I've
+discussed this issue with John; he mainly does not want that to happen
+for an empty package. The only empty language-defined package is Ada, and
+that is Pure so no change is needed at this time.]
-[Open issue: Some of these language-defined packages have categorization
-pragmas. Mixing pragmas and aspects is ugly. The author's preference is to
-change:
+For instance, we'll change
package Ada.Command_Line is
pragma Preelaborate(Command_Line);
@@ -786,23 +800,6 @@
package Ada.Command_Line
with Preelaborate, Nonblocking is
-An alternative that would make John happy would be to define a Nonblocking
-library unit pragma to use as an alternative to the aspect for library units:
-
- package Ada.Command_Line is
- pragma Preelaborate(Command_Line);
- pragma Nonblocking(Command_Line);
-
-We didn't do this pending a full ARG discussion, since it would add even more
-wording to an already large AI, and many of us have a strong preference for
-aspects in all cases. It also would not extend well to other kinds of
-contracts (global, exceptions, etc.) where more is needed than just a
-present/absent value.
-
-(John was the major holdout in the past. Has he moderated his view with
-experience? Or has he retired yet? ;-)
-End Open issue.]
-
[Lengthy Editor's note:
We intend that language-defined subprograms are nonblocking
@@ -817,8 +814,8 @@
nonblocking.
Non-generic units that are pure are automatically nonblocking as specified in
-9.5 (these are noted below). Other units should explicitly have Nonblocking
-specified.
+9.5 (these are noted below). Other units should explicitly have aspect
+Nonblocking specified.
We'll handle the containers in AI12-0112-1 (the AI that defines preconditions
for the container operations); it probably makes the most sense to add all of
@@ -826,6 +823,7 @@
The entire list of non-container units is:
+ Ada - A.2 - Pure
Ada.Assertions — 11.4.2 - Pure
Ada.Asynchronous_Task_Control — D.11 - Nonblocking => True
Ada.Calendar — 9.6 - Nonblocking => True
@@ -1002,7 +1000,8 @@
Items marked "(* generic)" have Nonblocking given as a formula. This
automatically matches the nonblocking setting to that of the actual
-parameters (see the !discussion for more on this).
+parameters (see the !discussion for more on this). The containers will be
+like this as well.
Items marked "(** String routines)" have Get/Put routines that operate only on
Strings -- those explicitly have Nonblocking => True specified. That's in
@@ -1091,7 +1090,8 @@
nonblocking at run-time, we don't allow specifying the attribute
directly on an individual protected operation. However, we allow
specifying Nonblocking on a protected unit to determine the setting for
-all of the enclosed protected operations.
+all of the enclosed protected operations. This allows rejection of
+protected operations that call or use allows blocking operations.
We only allow specifying a conforming expression (essentially a
confirming value) of Nonblocking on a generic
@@ -1957,6 +1957,35 @@
reviewed this draft yet, so I wouldn't be surprised if new issues emerge.
As always, any comments are welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, October 13, 2017 3:09 PM
+
+New paragraph:
+
+ For an inherited primitive subprogram, if the subprogram is null
+ or abstract, the subprogram is nonblocking if the corresponding
+ subprogram of any ancestor is nonblocking. If the subprogram is
+ neither null nor abstract, the subprogram is nonblocking if and
+ only if the corresponding subprogram of the parent is
+ nonblocking.
+
+immediately preceding:
+
+ Unless directly specified, overridings of dispatching operations
+ inherit this aspect.
+
+
+Update the following paragraph by adding a sentence (in {}):
+
+ A subprogram shall be nonblocking if it overrides a nonblocking
+ dispatching operation. An entry shall not implement a nonblocking
+ procedure. { If an inherited subprogram allows blocking, then
+ the corresponding subprogram of each ancestor shall allow blocking.}
+
+[Editor's note: These were added to version /13 of the AI.]
****************************************************************
Questions? Ask the ACAA Technical Agent