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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0344-1.txt

--- ai12s/ai12-0344-1.txt	2019/10/02 01:49:33	1.2
+++ ai12s/ai12-0344-1.txt	2020/01/14 02:01:57	1.3
@@ -1,4 +1,4 @@
-!standard 5.5.3(16/5)                                  19-09-30  AI12-0344-1/01
+!standard 5.5.3(16/5)                                  20-01-12  AI12-0344-1/02
 !standard 5.5.3(20/5)
 !standard 5.5.3(22/5)
 !class Amendment 19-09-30
@@ -10,20 +10,20 @@
 !summary
 
 Allows_Exit and Parallel_Iterator can only be applied to subprograms with
-a single access-to-procedure parameter.
+a single access-to-subprogram parameter.
 
-Aspect Parallel_Calls is defined to check that a procedure can be called
+Aspect Parallel_Calls is defined to check that a subprogram can be called
 in parallel.
 
 !problem
 
-The legality requirement for Allows_Exit and Parallel_Iterator aspects says 
-that the callable entity shall have at least one parameter of an anonymous 
-access-to-subprogram type. If there are multiple such parameters, how do we 
-know which parameter is the "loop body procedure" which is mentioned in the 
+The legality requirement for Allows_Exit and Parallel_Iterator aspects says
+that the callable entity shall have at least one parameter of an anonymous
+access-to-subprogram type. If there are multiple such parameters, how do we
+know which parameter is the "loop body procedure" which is mentioned in the
 description of the semantics of the aspects?
 
-If the user explicitly passes a procedure to a subprogram with 
+If the user explicitly passes a subprogram to a subprogram with
 Parallel_Iterator => True, there is no checking on that subprogram (unlike
 what happens when the subprogram is used in a procedural iterator loop).
 
@@ -33,46 +33,64 @@
 
 !wording
 
+Add after 5.5.3(15/5):
+
+  In a procedural iterator, the Parallel_Calls aspect (see 9.10.1) of
+  the loop body procedure is True if the reserved word *parallel* occurs
+  in the corresponding loop statement, and False otherwise.
+
 Modify 5.5.3(16/5):
 
-The following aspects may be specified for a callable entity S that has at 
-{exactly}[least] one formal parameter of an anonymous 
-access-to-{procedure}[subprogram] type:
-
-[Editor's note: A loop body procedure can't be a function, so why allow a
-parameter that is an access-to-function?]
-
-Add after 5.5.3(20/5):
-
-The following aspect can be specified for a procedure P:
-
-Parallel_Calls
-
-The Parallel_Calls aspect is of type Boolean. The specified value shall be 
-static. The Parallel_Calls aspect of an inherited primitive procedure is True 
-if Parallel_Calls is True either for the corresponding procedure of the 
-progenitor type or for any other inherited procedure that it overrides. 
-If not specified or inherited as True, the Parallel_Calls aspect of a 
-procedure is False.
-
-Specifying the Parallel_Calls aspect to be True for a procedure indicates that 
-the procedure may be safely called in parallel. Conflict checks (if required by 
-the Conflict_Check_Policy in effect (see 9.10.1)) are made on the procedure
-assuming that multiple concurrent calls exist.
-
-The Parallel_Calls aspect of a loop body procedure is True if the reserved
-word *parallel* occurs in the corresponding loop statement, and False 
-otherwise.
+  The following aspects may be specified for a callable entity S that
+  has {exactly}[at least] one formal parameter of an anonymous
+  access-to-subprogram type:
 
 Add after 5.5.3(22/5):
 
-The actual loop body procedure passed to an explicit call of a subprogram for
-which the Parallel_Iterator aspect is True shall have a Parallel_Calls aspect
-True.
+  If the actual parameter of an anonymous access-to-subprogram type,
+  passed in an explicit call of a subprogram for which the
+  Parallel_Iterator aspect is True, is of the form P'Access, the
+  designated subprogram P shall have a Parallel_Calls aspect True (see
+  9.10.1).
+
+Add after 9.10.1(22/5):
+
+  The following aspect can be specified for a subprogram P:
+
+  Parallel_Calls
+
+    The Parallel_Calls aspect is of type Boolean. The specified value
+    shall be static. The Parallel_Calls aspect of an inherited primitive
+    subprogram is True if Parallel_Calls is True either for the
+    corresponding subprogram of the progenitor type or for any other
+    inherited subprogram that it overrides. If not specified or
+    inherited as True, the Parallel_Calls aspect of a subprogram is
+    False.
+
+    Specifying the Parallel_Calls aspect to be True for a subprogram
+    indicates that the subprogram can be safely called in parallel.
+    Conflict checks (if required by the Conflict_Check_Policy in effect)
+    are made on the subprogram assuming that multiple concurrent calls
+    exist. [Redundant: Such checks need not be repeated at each call of the
+    subprogram in a parallel iteration context.]
 
 !discussion
 
-None.
+As indicated in the !problem, to prevent ambiguity, we limit the aspects
+Allows_Exit and Parallel_Iterator to subprograms with a single parameter
+of an anonymous access-to-subprogram type. We allow both access-to-function
+and access-to-procedure parameters, as these capabilities might be
+relevant in constructs where a function rather than a
+procedure is being called repeatedly. (Such as a parallel aggregate, if such
+a thing exists.)
+
+We add a new aspect, Parallel_Calls, to apply to subprograms that are
+expected to be called by a subprogram with the Parallel_Iterator aspect,
+or to be called in other parallel iteration contexts. Such a subprogram
+is checked according to the Confict_Check_Policy in effect, to determine
+whether it can be safely called concurrently. This enables some
+conflict checking to be performed modularly, without relying on a
+specified Global aspect.
 
 !ASIS
 
@@ -90,9 +108,9 @@
 Sent: Monday, August 19, 2019  8:46 PM
 
 I believe we have a bug in the legality requirement for Allows_Exit and
-Parallel_Iterator aspects.  It currently says that the callable entity 
-shall have at least one parameter of an anonymous access-to-subprogram type.  
-I don't think that really makes sense.  I think we should say "exactly one" 
+Parallel_Iterator aspects.  It currently says that the callable entity
+shall have at least one parameter of an anonymous access-to-subprogram type.
+I don't think that really makes sense.  I think we should say "exactly one"
 because otherwise how do we know which parameter is the "loop body procedure"
 which is mentioned in the description of the semantics of the aspects.
 
@@ -109,27 +127,27 @@
 Sent: Wednesday, August 21, 2019  6:37 PM
 
 The latest version of AI12-0326-2 introduces the Parallel_Iterator aspect as
-part of a parallel procedural iterator.  If you explicitly call a procedure 
-with Parallel_Iterator => True rather than as part of a parallel procedural 
+part of a parallel procedural iterator.  If you explicitly call a procedure
+with Parallel_Iterator => True rather than as part of a parallel procedural
 iterator, it seems that we might want to impose a requirement on the procedure
-passed as an access-to-subp parameter (which corresponds to the "loop body 
-procedure" created implicitly by the compiler).  
+passed as an access-to-subp parameter (which corresponds to the "loop body
+procedure" created implicitly by the compiler).
 
-My suggestion is that we require that this procedure have aspect 
-Parallel_Calls => True.  This will indicate that the programmer recognized 
-this routine would be called in parallel, and would cause the compiler to 
-check that this procedure can safely be called in parallel with itself, 
-i.e. re-entrantly, if required by the Conflict_Check_Policy in effect at the 
-point of declaration.  Even if no conflict checks are being performed, the 
-presence of this aspect would indicate the programmer knew (and the reader 
+My suggestion is that we require that this procedure have aspect
+Parallel_Calls => True.  This will indicate that the programmer recognized
+this routine would be called in parallel, and would cause the compiler to
+check that this procedure can safely be called in parallel with itself,
+i.e. re-entrantly, if required by the Conflict_Check_Policy in effect at the
+point of declaration.  Even if no conflict checks are being performed, the
+presence of this aspect would indicate the programmer knew (and the reader
 will learn) it might be used in such a context.
 
-When the compiler implicitly creates such a "loop body" procedure, it can 
-also implicitly set Parallel_Calls => True. 
+When the compiler implicitly creates such a "loop body" procedure, it can
+also implicitly set Parallel_Calls => True.
 
-This came up because I am doing hand-expansions of various examples that use 
-parallel procedural iterators, and it seemed odd that there was no checking 
-implied.  I suppose we could liberalize this a bit to say that either 
+This came up because I am doing hand-expansions of various examples that use
+parallel procedural iterators, and it seemed odd that there was no checking
+implied.  I suppose we could liberalize this a bit to say that either
 Parallel_Calls => True, or any Global beyond "null" is synchronized.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent