CVS difference for 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