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

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

--- ai12s/ai12-0427-1.txt	2021/06/03 02:45:18	1.6
+++ ai12s/ai12-0427-1.txt	2021/06/08 05:46:02	1.7
@@ -1,4 +1,4 @@
-!standard 3.5(56.4/3)                                   21-06-02  AI12-0427-1/05
+!standard 3.5(56.4/3)                                   21-06-03  AI12-0427-1/06
 !standard 3.6(22.2/3)
 !standard 4.1.3(13.1/5)
 !standard 4.2.1(0/5)
@@ -20,6 +20,7 @@
 !standard B.3(65.1/5)
 !class Amendment 21-05-07
 !status Amendment 1-2012 21-05-07
+!status ARG Approved 14-0-1  21-06-03
 !status work item 21-05-07
 !status received 21-05-07
 !priority Low
@@ -27,8 +28,8 @@
 !subject Fixups from WG 9 review
 !summary
 
-(1) Add rules about the subtypes of Put_Image and the propagation of 
-exceptions from implicit calls to Put_Image.
+(1) Add rules about the propagation of exceptions from implicit calls to 
+Put_Image.
 
 (2) Delete 8.5(5); it is not true in Ada 202x (and part of it was not true
 in Ada 2005 or Ada 2012, either).
@@ -79,10 +80,10 @@
 (1) Stream-oriented attributes define the subtype of the parameter of the 
 associated subprograms with 13.13.2(51/3). We don't have any similar rule 
 for Put_Image in 4.10. The definition of Put_Image seems to suggest that 
-the parameter is of type T, but type do not have names in Ada -- one always
+the parameter is of type T, but types do not have names in Ada -- one always
 has to specify a subtype.
 
-Additionally, the RM we doesn't mention that the implicit calls of Put_Image
+Additionally, the RM doesn't mention that the implicit calls of Put_Image
 propagate any exceptions (including those caused by a subtype check
 failure).
 
@@ -188,7 +189,7 @@
 inherited routine (which makes the same call implicitly) is legal.
 
 Tucker notes that 6.4.1(15.1/5) says that this view conversion raises
-Program_Error. Therefore, there is no language bug in that code that does
+Program_Error. Therefore, there is no language bug because code that does
 not follow the principles cannot be executed. OTOH, the rule Tucker refers
 to was only intended to be used in generic bodies (and there is an AARM note
 to that effect). So implementers and users alike are likely to be confused.
@@ -228,7 +229,7 @@
 reserved word parallel". But that was not done for a parallel block, which
 uses the reserved work parallel.
 
-(15) AI12-0355-2 as well as the previous issue add aspect_specifications to
+(15) AI12-0355-2, as well as the previous issue, adds aspect_specifications to
 certain statements and expressions. 13.1.1(11/5) says:
 
   The usage names in an aspect_definition are not resolved at the point of the
@@ -265,7 +266,7 @@
 a requirement that corresponding global_names have to statically denote
 the same entity.
 
-Additionally, we now has "statically names" for objects, which allows
+Additionally, we now have "statically names" for objects, which allows
 selected and indexed names when those are known at compile-time. We should
 use that in 6.1.2(9/5) and in 4.9.1(1.5/5) to allow as much as possible in
 global aspects.
@@ -317,17 +318,9 @@
 [Editor's note: These changes have been applied to Draft 30 of the RM, even
 though they are not yet approved, in order that the draft reflect as much of
 the accepted WG 9 comments as possible.]
-
-(1) Add after 4.10(4/5):
 
-   For an aspect_specification or attribute_definition_clause specifying 
-   Put_Image, the subtype of the Arg parameter shall be the first subtype
-   or the base subtype if scalar, and the first subtype if not scalar.
-
-[Editor's note: This is really a Legality Rule, but we don't currently
-have such a section here. If we added one, the rule would be far away
-from the place where it makes sense. Note that stream-oriented attributes
-don't have Legality Rules section either.]
+(1) A version of the first problem also occurs in AI12-0435-1, and we
+chose to fix it there as that AI also includes other fixes.
 
 Add to the end of each of 4.10(28.2/5), 4.10(31/5), 4.10(34/5):
    Redundant[Any exception propagated by the call of S'Put_Image is
@@ -507,8 +500,8 @@
 
 (14) Replace 5.6.1(2/5) with:
 
-parallel_block_statement ::= 
-    parallel [aspect_specification] do
+  parallel_block_statement ::= 
+    parallel [(chunk_specification)] [aspect_specification] do
        handled_sequence_of_statements
     and
        handled_sequence_of_statements
@@ -516,16 +509,25 @@
        handled_sequence_of_statements}
     end do;
 
-Modify 5.6.1(3/5):
+  The chunk_specification, if any, of a parallel_block_statement shall be an 
+  /integer_/simple_expression.
 
-   {For the execution of a parallel_block_statement, the aspect_specification, 
-   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{, 
-   each of which} represents a separate logical thread of control{, 
-   executes}[ that proceeds] independently and concurrently. The 
-   parallel_block_statement is complete once every one of the 
-   handled_sequence_of_statements has completed, either by reaching the end 
-   of its execution, or due to a transfer of control out of the construct by
-   one of the handled_sequence_of_statements (see 5.1).
+Replace 5.6.1(3/5) with:
+
+  For the execution of a parallel_block_statement, the chunk_specification 
+  and the aspect_specification, if any, are elaborated in an arbitrary order.
+  After elaborating the chunk_specification, if any, a check is made that the
+  determined maximum number of chunks is greater than zero. If this check
+  fails, Program_Error is raised. 
+
+  Then, the various handled_sequence_of_statements are grouped into one or
+  more /chunks/, each with its own logical thread of control (see clause 9),
+  up to the maximum number of chunks specified by the chunk_specification, if
+  any. Within each chunk every handled_sequence_of_statements of the chunk is
+  executed in turn, in an arbitrary order. The parallel_block_statement is
+  complete once every one of the handled_sequence_of_statements has completed,
+  either by reaching the end of its execution, or due to a transfer of control
+  out of the construct by one of the handled_sequence_of_statements (see 5.1). 
 
 (15) Modify 13.1(11/5):
 
@@ -548,9 +550,9 @@
    The Global or Global'Class aspects (see 6.1.2) of two entities statically
    match if both consist of a single global_aspect_definition where each is 
    the reserved word null, or each is of the form 
-   “global_mode global_designator” with {each global_mode being} the same
+   "global_mode global_designator" with {each global_mode being} the same
    sequence of reserved words {and each global_designator being the same 
-   reserved word, or each being a global_name that statically denotes the 
+   reserved word, or each being a global_name that statically names the 
    same entity}.
 
 Modify 6.1.2(9/5):
@@ -560,9 +562,7 @@
 
 !discussion
 
-(1) The first paragraph is modeled on that found in 13.13.2(51/3) for
-stream-oriented attributes. The added sentences are modeled on 
-13.11(21.5/3) for calls to Allocate.
+(1) The added sentences are modeled on 13.11(21.5/3) for calls to Allocate.
 
 Note that we don't consistently mention exception propagation in the RM; 
 such wording is not needed since the definition of exception propagation in
@@ -777,7 +777,7 @@
 where each is the reserved word @b<null>, or each is of the form
 "@fa<global_mode> @fa<global_designator>" with each @fa<global_mode> being the
 same sequence of reserved words and each @fa<global_designator> being the same 
-reserved word, or each being a @fa<global_name> that statically denotes the 
+reserved word, or each being a @fa<global_name> that statically names the 
 same entity.
 
 A subtype @i<statically matches> another subtype of the same type if they have
@@ -1807,5 +1807,153 @@
    handled_sequence_of_statements has completed, either by reaching the end 
    of its execution, or due to a transfer of control out of the construct by
    one of the handled_sequence_of_statements (see 5.1).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 4, 2021  11:47 PM
+
+I noticed some minor problems with the rewording of 5.6.1(3/5) in AI12-0427-1. 
+A summary of a private thread between Tucker and I is given below.
+
+We intend to process this rewording of the rewording as an Editorial Review 
+change. It is a bit of a stretch for that (the missing check represents added
+semantics, even if obviously missing semantics). Therefore, if anyone wants to
+request a Letter Ballot on this change (essentially, objecting to handling
+this as an Editorial Review change), please speak up ASAP.
+
+
+Summary of private thread:
+
+From Randy Brukardt:
+
+We have in 5.6.1(3/5):
+
+   {For the execution of a parallel_block_statement, the chunk_specification 
+   and the aspect_specification, if any, are elaborated in an arbitrary order.
+   Then every}[Each] handled_sequence_of_statements{, each of which can} 
+   represent[s] a separate logical thread of control{ (up to the maximum
+   specified by the value of the chunk_specification, if any), executes}[ that
+   proceeds] independently and concurrently{, again, up to the maximum if 
+   specified}. The parallel_block_statement is complete once every one of the 
+   handled_sequence_of_statements has completed, either by reaching the end 
+   of its execution, or due to a transfer of control out of the construct by
+   one of the handled_sequence_of_statements (see 5.1).
+
+I won't mention the department of redundancy department repeat of the maximum 
+(there's nothing like it in the loop wording). 
+
+But two things seem to be missing here:
+   First, how do the limbs of a parallel block execute if there aren't enough 
+   logical threads of control for all of them? Previously, there always were
+   enough logical threads, and they could be mapped to physical threads
+   however the implementation wished. But now we seem to have a limit on the
+   number of logical threads, and we never say anything about how a limb
+   executes if it doesn't have a thread.
+
+   Second, for loops have a check to ensure that the number of chunks is 
+   positive (see 5.5(8.1/5)). This is implied (very weakly!!) for reduction
+   expressions via the references to 5.5 in 4.5.10(20-21/5). But we have no
+   such check here, nor even a way to hand-wave a check via a reference to 
+   the check in 5.5.
+
+So, what happens with 
+     parallel (-2) do
+       ...
+     end do;
+
+One would hope this raised Program_Error like a loop would. But why??
+
+From Tucker Taft:
+
+> First, how do the limbs of a parallel block execute if there aren't 
+> enough logical threads of control for all of them?
+
+My intent was that they execute independently and concurrently only if we 
+stay within the maximum.  Otherwise, they execute sequentially.  But I agree 
+that my attempt to avoid complete rewrite was doomed.
+
+...
+>One would hope this raised Program_Error like a loop would. But why??
+
+Agreed, we should be consistent here.
+
+Here is my attempt. I have given up on using {} and [] to indicate what is 
+new and what is pre-existing.  I have dropped the "handled_" part ;-)
+
+Replace 5.6.1(3/5) with:
+
+  For the execution of a parallel_block_statement, the chunk_specification
+  and the aspect_specification, if any, are elaborated in an arbitrary order.
+  The various
+  sequence_of_statements are grouped into one or more /chunks/, each with
+  its own logical thread of control (see clause 9), up to the maximum number
+  of chunks specified by the chunk_specification, if any. Within each chunk
+  every sequence_of_statements of the chunk is executed in turn, in an
+  arbitrary order. The parallel_block_statement is complete once every one
+  of the sequence_of_statements has completed, either by reaching the end of
+  its execution, or due to a transfer of control out of the construct by one
+  of the sequence_of_statements (see 5.1). After elaborating the
+  chunk_specification, if any, a check is made that the determined maximum
+  number of chunks is greater than zero. If this check fails, Program_Error
+  is raised.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Saturday, June 5, 2021  2:29 AM
+
+Shouldn't last two sentences of the new wording come after the first sentence?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, June 6, 2021  12:53 AM
+
+I wondered that, too. I eventually concluded it didn't matter that much, but 
+the loop wording uses two separate paragraphs. Here, that would look something
+like:
+ 
+Replace 5.6.1(3/5) with: 
+
+  For the execution of a parallel_block_statement, the chunk_specification 
+  and the aspect_specification, if any, are elaborated in an arbitrary order.
+  After elaborating the chunk_specification, if any, a check is made that the
+  determined maximum number of chunks is greater than zero. If this check
+  fails, Program_Error is raised. 
+
+  Then, the various sequence_of_statements are grouped into one or more
+  /chunks/, each with its own logical thread of control (see clause 9), up to
+  the maximum number of chunks specified by the chunk_specification, if any. 
+  Within each chunk every sequence_of_statements of the chunk is executed in 
+  turn, in an arbitrary order. The parallel_block_statement is complete once 
+  every one of the sequence_of_statements has completed, either by reaching
+  the end of its execution, or due to a transfer of control out of the
+  construct by one of the sequence_of_statements (see 5.1). 
+ 
+Not certain if this is better, but it's more consistent with the wording for 
+the parallel loops. Agree? Disagree? Don't care? ;-)
+ 
+****************************************************************
+
+From: Jeff Cousins
+Sent: Sunday, June 6, 2021  2:38 AM
+
+That seems much better to me.  Otherwise we might need another AI later to 
+clarify the order in which things happen (as with 343).
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Sunday, June 6, 2021  7:52 AM
+
+I agree this way is more consistent with the related wording.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, June 6, 2021  8:15 AM
+
+Fine with me.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent