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

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0064-1.txt

--- ai12s/ai12-0064-1.txt	2014/10/07 04:39:14	1.5
+++ ai12s/ai12-0064-1.txt	2014/11/13 04:15:28	1.6
@@ -1,4 +1,4 @@
-!standard 9.5.1(18)                                13-11-12    AI12-0064-1/02
+!standard 9.5.1(18)                                14-10-14    AI12-0064-1/03
 !class Amendment 13-04-22
 !status work item 13-04-22
 !status received 13-04-22
@@ -21,20 +21,22 @@
 
 !proposal
 
-Add an aspect Nonblocking.
+Add an aspect Nonblocking (or the converse, Potentially_Blocking?)
 
-!wording
-
 Add at the end of 9.5.1 (as continuation of bounded error section?)
-
-  For a callable entity or a generic subprogram, the following
-  language-defined representation aspect may be specified:
 
-      The type of aspect Nonblocking is Boolean. When aspect Nonblocking is
-      True for an entity, the entity is said to be nonblocking.
-      If directly specified, the aspect_definition shall be a static
-      expression. [This aspect is never inherited;] if not directly
-      specified, the aspect is False.
+  For a callable entity, a generic subprogram, a package, or a generic 
+  package, the following language-defined representation aspect may be
+  specified:
+ 
+      The type of aspect Nonblocking is Boolean. When aspect Nonblocking
+      is True for an entity, the entity is said to be nonblocking. If
+      directly specified, the aspect_definition shall be a static
+      expression. This aspect is inherited by overridings of
+      dispatching subprograms; if not specified, the aspect is
+      determined by the setting for the innermost package or generic
+      package.  If not specified for a library package or generic
+      library package, the default is False.
 
       When a callable entity is nonblocking, a call to the
       entity is considered to be within a protected operation for
@@ -81,6 +83,20 @@
 is just a bounded error and the "mistake" can be ignored with the usual
 consequences.)
 
+We have provided package-level defaults, given that many packages will
+have all of their subprograms non-blocking.  We might want to make the
+default for a Pure package to be nonblocking, as that is almost always
+the case, since blocking typically implies the use of some kind of
+global lock.
+
+"Nonblocking" is shorter than "Potentially_Blocking" but the latter
+matches the RM terminology better, so might be preferred (with corresponding
+complementary semantics!).
+
+It will be necessary to sprinkle appropriate annotations throughout the
+language-defined packages to match the current blocking vs. 
+potentially-blocking categorizations.
+
 !example
 
 TBD.
@@ -91,7 +107,7 @@
 
 !ACATS test
 
-ACATS B-Tests (to test 4.3.3(17-18) and the new rules) and C-Tests.
+ACATS B-Tests and C-Tests.
 
 !appendix
 
@@ -148,5 +164,15 @@
 In the absence of such an explicit package-wide default, the default for
 Potentially_Blocking would be True, and the default for Global would be (In_Out
 => all) in a normal package, and null in a declared-pure package.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 14, 2014  12:04 PM
+
+Here is a very modest update to AI-0064 on the Nonblocking aspect (or
+Potentially_Blocking if you prefer).  I hadn't realized it was on my list of
+homework until today...
+[Editor's note: This is version /03 of the AI.]
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent