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

Differences between 1.17 and version 1.18
Log of other versions for file 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