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

Differences between 1.11 and version 1.12
Log of other versions for file ai12s/ai12-0266-1.txt

--- ai12s/ai12-0266-1.txt	2019/01/11 08:27:41	1.11
+++ ai12s/ai12-0266-1.txt	2019/01/13 06:27:25	1.12
@@ -1,4 +1,4 @@
-!standard 5.5.1(4/3)                                  19-01-10  AI12-0266-1/08
+!standard 5.5.1(4/3)                                  19-01-12  AI12-0266-1/09
 !standard 5.5.1(6/4)
 !standard 5.5.1(11/3)
 !standard 5.5.2(4/3)
@@ -16,8 +16,11 @@
 
 AI12-0119 provides mechanisms that can be used to iterate in parallel over the
 elements of an array. One would expect that there would be a similar need to
-be able to iterate over the elements of a container in parallel. Should such
-a capability be provided in Ada? (Yes).
+iterate over the elements of a container in parallel. Should such a
+capability be provided in Ada? (Yes). Similarly, AI12-0251 adds support
+for explicit chunking of parallel loops for a loop_parameter_specification.
+Should explicit chunking support also be provided for an iterater_specification,
+to facilitate explicit chunking of parallel iteration over containers? (Yes).
 
 !proposal
 
@@ -44,11 +47,12 @@
 sequential iteration for loops that do not have the parallel reserved keyword.
 
 A parallel iterator provides a Split_Into_Chunks procedure that can be used to
-associate with the iterator a set of cursors that define the chunk boundaries
-for parallel iteration. Each cursor can be assigned to a different logical
-thread of control and identifies the first element of a different chunk of
-iterations where each chunk can be iterated through in parallel with other
-chunks to collectively cover all the elements of the container.
+associate with the iterator a set of cursors and corresponding chunks that
+define the chunk boundaries for parallel iteration. Each cursor can be assigned
+to a different logical thread of control and identifies the first element of
+a different chunk of iterations where each chunk can be iterated through in
+parallel with other chunks to collectively cover all the elements of the
+container.
 
 The starting cursor for each chunk of iteration can be obtained by calling the
 First_In_Chunk operation, passing in the chunk index of the split as a parameter
@@ -60,7 +64,8 @@
 of a chunk, respectively.
 
 In addition, the loop syntax is extended to allow the loops with iterator
-specifications to have the parallel keyword.
+specifications to have the parallel keyword and to optionally specify a
+chunk_specification.
 
 !wording
 
@@ -69,6 +74,7 @@
   iteration_scheme ::= while condition
      | for loop_parameter_specification
      | for iterator_specification
+     | for procedural_iterator
      | parallel [(chunk_specification)]
        for loop_parameter_specification
      | parallel [(chunk_specification)]
@@ -197,70 +203,92 @@
 
 Modify AARM 5.5.2(8.a/5):
 
-Ramification: The loop parameter{s} of a generalized iterator {have}[has] the
+Ramification: The loop parameter of a generalized iterator has the
 same accessibility as the loop statement. This means that the loop parameter
 object{s} {are}[is] finalized when the loop statement is left. ([It]{They} also
-may be finalized as part of assigning a new value to the loop parameter{s}.) For
-array component iterators, the loop parameter{s each} directly denotes an
-element of the array and [has]{have} the accessibility of the associated array.
-For container element iterators, the loop parameter{s each} denotes the result
+may be finalized as part of assigning a new value to the loop parameter.) For
+array component iterators, the loop parameter directly denotes an
+element of the array and has the accessibility of the associated array.
+For container element iterators, the loop parameter denotes the result
 of [the]{an} indexing function call (in the case of a constant indexing) or a
 generalized reference thereof (in the case of a variable indexing). Roughly
-speaking, the loop parameter{s have} [has] the accessibility level of a single
+speaking, the loop parameter has the accessibility level of a single
 iteration of the loop. More precisely, the function result (or the generalized
 reference thereof) is considered to be renamed in the declarative part of a
 notional block statement which immediately encloses the loop's
-sequence_of_statements; the accessibility of the loop parameter{s are} [is] that
+sequence_of_statements; the accessibility of the loop parameter is that
 of the block statement.
 
 Modify 5.5.2(10/3):
 
-For a generalized iterator, the loop parameter{s are} [is] created, the
-iterator_name is evaluated, and the denoted iterator object becomes the
-loop iterator. In a forward generalized iterator, the operation First of the
-iterator type is called on the loop iterator, to produce the initial value for
-the loop parameter. If the result of calling Has_Element on the initial value is
-False, then the execution of the loop_statement is complete. Otherwise, the
-sequence_of_statements is executed and then the Next operation of the iterator
-type is called with the loop iterator and the current value of the loop
-parameter to produce the next value to be assigned to the loop parameter. This
-repeats until the result of calling Has_Element on the loop parameter is False,
-or the loop is left as a consequence of a transfer of control. For a reverse
-generalized iterator, the operations Last and Previous are called rather than
-First and Next.
+For a generalized iterator {without the reserved word parallel},
+the loop parameter is created, the iterator_name is evaluated, and the denoted
+iterator object becomes the loop iterator. In a forward generalized iterator,
+the operation First of the iterator type is called on the loop iterator, to
+produce the initial value for the loop parameter. If the result of calling
+Has_Element on the initial value is False, then the execution of the loop_statement
+is complete. Otherwise, the sequence_of_statements is executed and then
+the Next operation of the iterator type is called with the loop iterator
+and the current value of the loop parameter to produce the next value to
+be assigned to the loop parameter. This repeats until the result of calling
+Has_Element on the loop parameter is False, or the loop is left as a
+consequence of a transfer of control. For a reverse generalized iterator
+{without the reserved word parallel},
+the operations Last and Previous are called rather than First and Next.
 
+
 Add after 5.5.2(10/3):
 
-For a parallel generalized iterator, the operation Split_Into_Chunks of the
-iterator type is then called, with the Max_Chunks parameter specified as the
-upper bound for the number of loop parameter objects (and the number of
-logical threads of control) to be associated with the iterator. The number of
-loop parameters that were created is determined by calling the Chunk_Count
-operation of the iterator. Each loop parameter can be assigned to a different
-logical thread of control, with an ordinal chunk index
-value. The Initial cursor values to be associated with each loop parameter is
-determined by calling the First_In_Chunk operation of the iterator using the
-chunk index value of the loop parameter object as the Chunk parameter for the
-call. The sequence_of_statements is executed for each loop parameter object and
-the Next_In_Chunk operation of the iterator type is called with the chunk index
-value of the loop parameter object and the current value of the loop parameter
-to produce the next value to be assigned to a given loop parameter. This
-repeats until the result of calling Has_Element on the loop parameter is False,
-or the loop is left as a consequence of a transfer of control.  For a reverse
-parallel generalized iterator, the operations Last_In_Chunk and Previous_In_Chunk
+The evaluation of a parallel generalized iterator first evaluates the
+chunk_specification, if any, and then the operation Split_Into_Chunks of
+the iterator type is called, with the Max_Chunks parameter specified
+as the upper bound for the number of loop parameter objects (and the number
+of logical threads of control) to be associated with the iterator. The
+corresponding actual parameter for Max_Chunks is determined by the
+chunk_specification, if present, otherwise the value is implementation defined.
+The number of chunks and loop parameters for the loop is determined by
+calling the Chunk_Count operation of the iterator. Each chunk has its own
+logical thread of control with its own copy of the loop parameter.
+
+     AARM To Be Honest: This wording does not describe when the loop parameter
+     object(s) are created. That creation has no side-effects (other than
+     possibly raising Storage_Error, but anything can do that), so we
+     simplified the wording by leaving it out. Each object has to be created
+     before any iteration that depends on it starts, but we do not (for
+     instance) require that the objects are all created at once at the start
+     of the loop.
+
+If a chunk_specification with a discrete_subtype_definition is present,
+then the logical thread of control associated with a given chunk has its
+own copy of the chunk parameter initialized with a distinct value from
+the discrete subtype defined by the discrete_subtype_definition.
+
+In a forward parallel generalized iterator, the operation First_In_Chunk
+of the iterator type is called on the loop iterator with the corresponding
+chunk parameter to produce the initial value for the loop parameter.
+If the result of calling Has_Element on the initial value is
+False, then the execution of the loop_statement is complete. Otherwise, the
+sequence_of_statements is executed and then the Next_In_Chunk operation of
+the iterator type is called with the loop iterator, the current value of
+the loop parameter, and the corresponding chunk parameter to produce the
+next value to be assigned to the loop parameter. This repeats
+until the result of calling Has_Element on the loop parameter is False, or
+the loop is left as a consequence of a transfer of control. For a reverse
+generalized iterator, the operations Last_In_Chunk and Previous_In_Chunk
 are called rather than First_In_Chunk and Next_In_Chunk.
 
 AARM Note
 
-The number of loop parameters specified for the Max_Chunks parameter of the
-Split_Into_Chunks call is only a recommendation by the implementation. A
-container implementation may choose a lower value if a more optimal split can be
-determined. For instance, a tree based container might create the split based on
-the number of branches at the top levels of the tree.
+The Max_Chunks parameter of the Split_Into_Chunks procedure is an upper
+bound for the number of chunks to be associated with a loop. A container
+implementation may opt for a lower value for the number of chunks if a
+more optimal split can be determined. For instance, a tree based container
+might create the split based on the number of branches at the top levels of the
+tree.
 
 Modify AARM 5.5.2(10.a/4):
 
-Ramification: The loop parameter{s} of a generalized iterator [is a]{are}
+Ramification: The loop parameter of a generalized iterator [is a]{denotes}
 variable{s} of which the user only has a constant view. It follows the normal
 rules for a variable of its nominal subtype. In particular, if the nominal
 subtype is indefinite, the variable is constrained by its initial value.
@@ -271,67 +299,113 @@
 
 Modify 5.5.2(11/3):
 
-For an array component iterator, the iterable_name is evaluated and the denoted
-array object becomes the array for the loop. If the array for the loop is a null
-array, then the execution of the loop_statement is complete. Otherwise, the
-sequence_of_statements is executed with [the] loop parameter{s that collectively
-denote} [denoting] each component of the array for the loop{. If the iterator is
-not a parallel array component iterator, the loop is iterated} using a canonical
-order of components, which is last dimension varying fastest (unless the array
-has convention Fortran, in which case it is first dimension varying fastest).
-For a forward array component iterator, the iteration starts with the component
-whose index values are each the first in their index range, and continues in the
+[For]{The evaluation of} an array component iterator {first evaluates the
+chunk_specification, if any}, {and then} the iterable_name is evaluated and
+the denoted array object becomes the array for the loop. If the array for the
+loop is a null array, then the execution of the loop_statement is complete.
+Otherwise, the sequence_of_statements is executed with the loop parameter
+denoting each component of the array for the loop{. If the iterator is not a
+parallel array component iterator, the loop is iterated} using a canonical order
+of components, which is last dimension varying fastest (unless the array has
+convention Fortran, in which case it is first dimension varying fastest). For a
+forward array component iterator, the iteration starts with the component whose
+index values are each the first in their index range, and continues in the
 canonical order. For a reverse array component iterator, the iteration starts
 with the component whose index values are each the last in their index range,
 and continues in the reverse of the canonical order. {For a parallel array
 component iterator, the order of iteration is arbitrary.} The loop iteration
 proceeds until the sequence_of_statements has been executed for each component
 of the array for the loop, or until the loop is left as a consequence of a
-transfer of control.
+transfer of control. If the loop is a parallel loop, each chunk has its own
+logical thread of control with its own copy of the loop parameter; otherwise (a
+/sequential loop/), a single logical thread of control performs the loop, and
+there is a single copy of the loop parameter. Each logical thread of control
+handles a distinct chunk of the components of the array for the loop such that
+all components are covered with no overlaps. Within each logical thread of
+control, the values are assigned to the loop parameter in increasing index order
+unless the reserved word reverse is present, in which case the values are
+assigned in decreasing order.
+
+AARM To Be Honest: This wording does not describe when the loop parameter
+object(s) are created. That creation has no side-effects (other than
+possibly raising Storage_Error, but anything can do that), so we
+simplified the wording by leaving it out. Each object has to be created
+before any iteration that depends on it starts, but we do not (for
+instance) require that the objects are all created at once at the start
+of the loop.
+
+If a chunk_specification with a discrete_subtype_definition is present,
+then the logical thread of control associated with a given chunk has its
+own copy of the chunk parameter initialized with a distinct value from
+the discrete subtype defined by the discrete_subtype_definition. The
+values of the chunk parameters are assigned such that they increase with
+increasing values of the component index associated with the corresponding
+loop parameters.
 
 Modify 5.5.2(12/3):
 
-For a container element iterator, the iterable_name is evaluated and the denoted
-iterable container object becomes the iterable container object for the loop.
-The default iterator function for the type of the iterable container object for
-the loop is called on the iterable container object and the result is the loop
-iterator. [An object] {Objects} of the default cursor subtype [is]{are} created
-(the loop cursor{s}).
+[For]{The evaluation of} a container element iterator {first evaluates the
+chunk_specification, if any}, {and then} the iterable_name is evaluated and
+the denoted iterable container object becomes the iterable container object
+for the loop. The default iterator function for the type of the iterable
+container object for the loop is called on the iterable container object
+and the result is the loop iterator. [An object] {Objects} of the default
+cursor subtype [is]{are} created (the loop cursor{s}).
 
 Modify 5.5.2(13/3): [into two paragraphs]
 
-For a forward container element iterator, the operation First of the iterator
-type is called on the loop iterator, to produce the initial value for the loop
-cursor. If the result of calling Has_Element on the initial value is False, then
-the execution of the loop_statement is complete. Otherwise, the
-sequence_of_statements is executed with the loop parameter denoting an indexing
-(see 4.1.6) into the iterable container object for the loop, with the only
-parameter to the indexing being the current value of the loop cursor; then the
-Next operation of the iterator type is called with the loop iterator and the
-loop cursor to produce the next value to be assigned to the loop cursor. This
-repeats until the result of calling Has_Element on the loop cursor is False, or
-until the loop is left as a consequence of a transfer of control. For a reverse
-container element iterator, the operations Last and Previous are called rather
-than First and Next.{
-
-For a parallel container element iterator, the operation Split_Into_Chunks
-of the iterator type is called, with the Max_Chunks parameter specified as the
-upper bound for the number of loop parameter objects to be associated with the iterator.
-The number of loop parameters that were created is determined by calling the
-Chunk_Count operation of the iterator. Each loop parameter can be assigned to a
-different logical thread of control, with an ordinal chunk index value. The
-Initial cursor values to be associated with each loop parameter is determined by
-calling the First_In_Chunk operation of the iterator using the chunk index value
-of the loop parameter object as the Chunk parameter for the call. The
-sequence_of_statements is executed for each loop parameter object and the Next_In_Chunk
-operation of the iterator type is called with the chunk index value of the loop
-parameter object and the current value of the loop parameter to produce the next
-value to be assigned to a given loop parameter. This repeats until the result of
-calling Has_Element on the loop parameter is False, or the loop is left as a
-consequence of a transfer of control.} If the loop parameter is a constant
-(see above), then the indexing uses the default constant indexing function for
-the type of the iterable container object for the
-loop; otherwise it uses the default variable indexing function.
+For a forward container element iterator {without the reserved word parallel},
+the operation First of the iterator type is called on the loop iterator,
+to produce the initial value for the loop cursor. If the result of calling
+Has_Element on the initial value is False, then the execution of the
+loop_statement is complete. Otherwise, the sequence_of_statements is executed
+with the loop parameter denoting an indexing (see 4.1.6) into the iterable container
+object for the loop, with the only parameter to the indexing being the
+current value of the loop cursor; then the Next operation of the iterator
+type is called with the loop iterator and [the] loop cursor to produce the
+next value to be assigned to the loop cursor. This repeats until the result
+of calling Has_Element on the loop cursor is False, or until the loop is
+left as a consequence of a transfer of control. For a reverse container
+element iterator {without the reserved word parallel}, the operations Last
+and Previous are called rather than First and Next.{
+
+The evaluation of a parallel container element iterator first evaluates the
+chunk_specification, if any, and then the operation Split_Into_Chunks of
+the iterator type is called, with the Max_Chunks parameter specified
+as the upper bound for the number of loop parameter objects (and the number
+of logical threads of control) to be associated with the iterator. The
+corresponding actual parameter for Max_Chunks is determined by the
+chunk_specification, if present, otherwise the value is implementation defined.
+The number of chunks and loop parameters for the loop is determined by
+calling the Chunk_Count operation of the iterator. Each chunk has its own
+logical thread of control with its own copy of the loop parameter.
+
+     AARM To Be Honest: This wording does not describe when the loop parameter
+     object(s) are created. That creation has no side-effects (other than
+     possibly raising Storage_Error, but anything can do that), so we
+     simplified the wording by leaving it out. Each object has to be created
+     before any iteration that depends on it starts, but we do not (for
+     instance) require that the objects are all created at once at the start
+     of the loop.
+
+If a chunk_specification with a discrete_subtype_definition is present,
+then the logical thread of control associated with a given chunk has its
+own copy of the chunk parameter initialized with a distinct value from
+the discrete subtype defined by the discrete_subtype_definition.
+
+In a forward parallel container element iterator, the operation First_In_Chunk
+of the iterator type is called on the loop iterator with the corresponding
+chunk parameter to produce the initial value for the loop parameter.
+If the result of calling Has_Element on the initial value is
+False, then the execution of the loop_statement is complete. Otherwise, the
+sequence_of_statements is executed and then the Next_In_Chunk operation of
+the iterator type is called with the loop iterator, the current value of the
+loop parameter, and the corresponding chunk parameter to produce the next
+value to be assigned to the loop parameter. This repeats until the result
+of calling Has_Element on the loop parameter is False, or the loop is left
+as a consequence of a transfer of control. For a reverse
+parallel container element iterator, the operations Last_In_Chunk and
+Previous_In_Chunk are called rather than First_In_Chunk and Next_In_Chunk.
 
 Modify 5.5.2(15/3):
 
@@ -360,12 +434,11 @@
 Modify A.18.2(230.2/3):
 
 Iterate returns a {parallel} reversible iterator object (see 5.5.1) that will
-generate a value for [a] loop parameter{s} (see 5.5.2) designating each node in
+generate a value for a loop parameter (see 5.5.2) designating each node in
 Container, starting with the first node and moving the cursor as per the Next
 function when used as a forward iterator, and starting with the last node and
 moving the cursor as per the Previous function when used as a reverse iterator
-{, and starting with all nodes simultaneously using the Split function
-to generate cursors for all the iterations of the loop when used as a parallel
+{, and starting with all nodes simultaneously when used as a parallel
 iterator}. Tampering with the cursors of Container is prohibited while the
 iterator object exists (in particular, in the sequence_of_statements of the
 loop_statement whose iterator_specification denotes this object). The iterator
@@ -381,12 +454,12 @@
 If Start is not No_Element and does not designate an item in Container, then
 Program_Error is propagated. If Start is No_Element, then Constraint_Error is
 propagated. Otherwise, Iterate returns a {parallel }reversible iterator object
-(see 5.5.1) that will generate a value for [a] loop parameter{s} (see 5.5.2)
+(see 5.5.1) that will generate a value for a loop parameter (see 5.5.2)
 designating each node in Container, starting with the node designated by Start
 and moving the cursor as per the Next function when used as a forward iterator,
 or moving the cursor as per the Previous function when used as a reverse
-iterator {, or all nodes simultaneously using the Split function when used as a
-parallel iterator}. Tampering with the cursors of Container is prohibited while
+iterator {, or all nodes simultaneously when used as a parallel iterator}.
+Tampering with the cursors of Container is prohibited while
 the iterator object exists (in particular, in the sequence_of_statements of the
 loop_statement whose iterator_specification denotes this object). The iterator
 object needs finalization.
@@ -409,12 +482,11 @@
 Modify A.18.3(144.2/3):
 
 Iterate returns a {parallel }reversible iterator object (see 5.5.1) that will
-generate a value for [a] loop parameter{s} (see 5.5.2) designating each node in
+generate a value for a loop parameter (see 5.5.2) designating each node in
 Container, starting with the first node and moving the cursor as per the Next
 function when used as a forward iterator, and starting with the last node and
 moving the cursor as per the Previous function when used as a reverse iterator
-{, and starting with all nodes simultaneously using the Split_Into_Chunks
-procedure to generate cursors for all the iterations of the loop when used as a
+{, and starting with all nodes simultaneously when used as a
 parallel iterator}. Tampering with the cursors of Container is prohibited while
 the iterator object exists (in particular, in the sequence_of_statements of the
 loop_statement whose iterator_specification denotes this object). The iterator
@@ -430,14 +502,14 @@
 If Start is not No_Element and does not designate an item in Container, then
 Program_Error is propagated. If Start is No_Element, then Constraint_Error is
 propagated. Otherwise, Iterate returns a {parallel} reversible iterator object
-(see 5.5.1) that will generate [a] value{s} for [a] loop parameter{s} (see
+(see 5.5.1) that will generate a value for a loop parameter (see
 5.5.2) designating each node in Container, starting with the node designated by
 Start and moving the cursor as per the Next function when used as a forward
 iterator, or moving the cursor as per the Previous function when used as a
-reverse iterator {or all nodes simultaneously using the Split_Into_Chunks
-procedure when used as a parallel iterator}. Tampering with the cursors of
-Container is prohibited while the iterator object exists (in particular, in the
-sequence_of_statements of the loop_statement whose iterator_specification
+reverse iterator {or all nodes simultaneously used as a parallel iterator}.
+Tampering with the cursors of Container is prohibited while the iterator
+object exists (in particular, in the sequence_of_statements of the
+loop_statement whose iterator_specification
 denotes this object). The iterator object needs finalization.
 
 Modify A.18.5(37.1/3):
@@ -453,11 +525,10 @@
 Modify A.18.5(61.2/3):
 
 Iterate returns a[n] {parallel} iterator object (see 5.5.1) that will generate
-[a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each node in
+a value for a loop parameter (see 5.5.2) designating each node in
 Container, starting with the first node and moving the cursor according to the
 successor relation {when used as a forward iterator, and starting with all nodes
-simultaneously using the Split_Into_Chunks procedure to generate cursors for all
-the iterations of the loop when used as a parallel iterator}. Tampering with the
+simultaneously when used as a parallel iterator}. Tampering with the
 cursors of Container is prohibited while the iterator object exists (in
 particular, in the sequence_of_statements of the loop_statement whose
 iterator_specification denotes this object). The iterator object needs
@@ -481,13 +552,12 @@
 Modify A.18.6(94.2/3):
 
 Iterate returns a {parallel} reversible iterator object (see 5.5.1) that will
-generate [a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each
+generate a value{s} for a loop parameter (see 5.5.2) designating each
 node in Container, starting with the first node and moving the cursor according
 to the successor relation when used as a forward iterator, and starting with the
 last node and moving the cursor according to the predecessor relation when used
-as a reverse iterator {, and starting with all nodes simultaneously using the
-Split_Into_Chunks procedure to generate cursors for all the iterations of the
-loop when used as a parallel iterator}. Tampering with the cursors of Container
+as a reverse iterator {, and starting with all nodes simultaneously when
+used as a parallel iterator}. Tampering with the cursors of Container
 is prohibited while the iterator object exists (in particular, in the
 sequence_of_statements of the loop_statement whose iterator_specification
 denotes this object). The iterator object needs finalization.
@@ -502,13 +572,13 @@
 If Start is not No_Element and does not designate an item in Container, then
 Program_Error is propagated. If Start is No_Element, then Constraint_Error is
 propagated. Otherwise, Iterate returns a {parallel} reversible iterator object
-(see 5.5.1) that will generate [a] value{s} for [a] loop parameter{s} (see
+(see 5.5.1) that will generate a value for a loop parameter (see
 5.5.2) designating each node in Container, starting with the node designated by
 Start and moving the cursor according to the successor relation when used as a
 forward iterator, or moving the cursor according to the predecessor relation
-when used as a reverse iterator {, or all nodes simultaneously using the
-Split_Into_Chunks procedure when used as a parallel iterator}. Tampering with
-the cursors of Container is prohibited while the iterator object exists (in
+when used as a reverse iterator {, or all nodes simultaneously when used
+as a parallel iterator}. Tampering with the cursors of Container is
+prohibited while the iterator object exists (in
 particular, in the sequence_of_statements of the loop_statement whose
 iterator_specification denotes this object). The iterator object needs
 finalization.
@@ -526,11 +596,10 @@
 Modify A.18.8(85.2/3):
 
 Iterate returns a[n] {parallel} iterator object (see 5.5.1) that will generate
-[a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each element in
+a value for a loop parameter (see 5.5.2) designating each element in
 Container, starting with the first element and moving the cursor according to
 the successor relation {when used as a forward iterator, and starting with all
-nodes simultaneously using the Split_Into_Chunks procedure to generate cursors
-for all the iterations of the loop when used as a parallel iterator.} Tampering
+nodes simultaneously when used as a parallel iterator.} Tampering
 with the cursors of Container is prohibited while the iterator object exists (in
 particular, in the sequence_of_statements of the loop_statement whose
 iterator_specification denotes this object). The iterator object needs
@@ -554,13 +623,12 @@
 Modify A.18.9(113.2/3):
 
 Iterate returns a {parallel} reversible iterator object (see 5.5.1) that will
-generate [a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each
+generate a value for a loop parameter (see 5.5.2) designating each
 element in Container, starting with the first element and moving the cursor
 according to the successor relation when used as a forward iterator, and
 starting with the last element and moving the cursor according to the
 predecessor relation when used as a reverse iterator {, and starting with all
-nodes simultaneously using the Split_Into_Chunks procedure to generate cursors
-for all the iterations of the loop when used as a parallel iterator}. Tampering
+nodes simultaneously when used as a parallel iterator}. Tampering
 with the cursors of Container is prohibited while the iterator object exists (in
 particular, in the sequence_of_statements of the loop_statement whose
 iterator_specification denotes this object). The iterator object needs
@@ -576,12 +644,12 @@
 If Start is not No_Element and does not designate an item in Container, then
 Program_Error is propagated. If Start is No_Element, then Constraint_Error is
 propagated. Otherwise, Iterate returns a {parallel} reversible iterator object
-(see 5.5.1) that will generate [a] value{s} for [a] loop parameter{s} (see
+(see 5.5.1) that will generate a value for a loop parameter (see
 5.5.2) designating each element in Container, starting with the element
 designated by Start and moving the cursor according to the successor relation
 when used as a forward iterator, or moving the cursor according to the
 predecessor relation when used as a reverse iterator {, or all nodes
-simultaneously using the Split_Into_Chunks procedure when used as a parallel
+simultaneously when used as a parallel
 iterator}. Tampering with the cursors of Container is prohibited while the
 iterator object exists (in particular, in the sequence_of_statements of the
 loop_statement whose iterator_specification denotes this object). The iterator
@@ -605,11 +673,10 @@
 Modify A.18.10(157/4)
 
 Iterate returns a[n] {parallel} iterator object (see 5.5.1) that will generate
-[a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each element node
+a value for a loop parameter (see 5.5.2) designating each element node
 in Container, starting from with the root node and proceeding in a depth-first
 order {when used as a forward_iterator, and starting with all nodes
-simultaneously using the Split_Into_Chunks procedure to generate cursors for all
-the iterations of the loop when used as a parallel iterator}. Tampering with the
+simultaneously when used as a parallel iterator}. Tampering with the
 cursors of Container is prohibited while the iterator object exists (in
 particular, in the sequence_of_statements of the loop_statement whose
 iterator_specification denotes this object). The iterator object needs
@@ -624,11 +691,11 @@
 
 If Position equals No_Element, then Constraint_Error is propagated. Otherwise,
 Iterate_Subtree returns a[n] {parallel} iterator object (see 5.5.1) that will
-generate [a] value{s} for [a] loop parameter{s} (see 5.5.2) designating each
+generate a value for a loop parameter (see 5.5.2) designating each
 element in the subtree rooted by the node designated by Position, starting from
 with the node designated by Position and proceeding in a depth-first order {when
-used as a forward iterator, or all nodes simultaneously using the
-Split_Into_Chunks procedure when used as a parallel iterator}. If Position
+used as a forward iterator, or all nodes simultaneously when used as a
+parallel iterator}. If Position
 equals No_Element, then Constraint_Error is propagated. Tampering with the
 cursors of the container that contains the node designated by Position is
 prohibited while the iterator object exists (in particular, in the
@@ -2109,6 +2176,114 @@
 RM draft. (If you don't have it yet, you ought to be able to download it soon.)
 
 That was too much for me to do tonight, so I'm leaving it for someone else.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, January 12, 2019  1:24 AM
+
+Here is an update to AI12-0266-1, Parallel Container Iteration [This is version
+/09 of the AI - Editor.]
+
+This is mostly to address the comments that Randy sent out against my previous
+version.
+
+In particular, support for the chunk specification syntax from AI-0251 was
+added to this AI. Also, the wording was modified to speak of the loop
+parameter being singular rather than plural. (There may be multiple copies of
+objects of the loop parameter, but conceptually only a single loop parameter.)
+This is now more consistent with the wording elsewhere.
+
+In addition, Randy had the following question about my previous change.
+
+"Modify AARM 5.5.2(8.a/5) and move into the Dynamic Semantics section after
+5.5.2
+
+I don't know why you added this move; the note is a Ramification of the way
+the loop parameters are declared (which determines their lifetime); while the
+consequences are dynamic semantics, the reason that they occur is because of
+the static semantics. That can't change just because of the parallel keyword,
+if you believe that is not true then we need wording to actually make this
+requirement.
+
+I left the note where is was, pending further justification."
+
+Basically, I was confused about the minutes from the Lexington meeting. I saw;
+
+They said;
+
+"The Static Semantics of 5.5.2 does not need any change at all.
+The AARM note changes are needed, though.
+
+The parallel discussion should be in 5.5.2(10, 12, 13)  that is, the Dynamic
+Semantics."
+
+I understood this as that the AARM note needed to move into Dynamic Semantics,
+and then I was thinking that accessibility levels was a dynamic semantic
+concept, so the comment was suggesting that the whole AARM note was mistakenly
+in the wrong place.
+
+Rereading this though, I see the intent was to just delete my wording changes
+to the static semantics, but dont delete the changes to the AARM note. And the
+two added sentences that were in the static semantics section should have been
+moved down to dynamic semantics.
+
+This new version hopefully makes things right. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 13, 2019  12:25 AM
+
+> Here is an update to AI12-0266-1, Parallel Container Iteration
+> 
+> This is mostly to address the comments that Randy sent out 
+> against my previous version.
+
+Thanks for doing this.
+
+One thing that jumped out at me:
+
+The corresponding actual parameter for Max_Chunks is determined by the 
+chunk_specification, if present, otherwise the value is implementation 
+defined.
+
+We certainly want this to be true, but you never said *how* Max_Chunks is 
+determined by the chunk_specification. I think you're trying to piggyback on 
+5.5(8.1/5), but it might be useful to say that somewhere. BTW, 5.5 says that 
+the chunk_specification is elaboration, because a loop_parameter_specification 
+is a declaration. And so is an iterator_specification, note that 5.5.2(9/3) 
+talks about "elaboration", not "evaluation". (Angels on a pin, I know.) Also, 
+each of these paragraphs starts with "For a <something>", and we might as well 
+stick with that.
+
+So I'd leave the sentence above alone, and change the first one:
+
+{For a}[The evaluation of a parallel] generalized iterator {with the reserved 
+word parallel} first {elaborates}[evaluates] the chunk_specification (see 5.5),
+if any, and then the operation Split_Into_Chunks ...
+
+Except that this is still missing the other parts (creating the loop parameter
+and evaluating the iterator_name} of setting up the loop. Since you separated 
+the wording into sequential and parallel descriptions (which I agree with), we
+have to repeat all of that stuff.
+
+So, something like:
+
+For a generalized iterator with the reserved word parallel, the 
+chunk_specification (see 5.5), if any, is first elaborated (see 5.5), then 
+the iterator_name is evaluated, and the denoted iterator object becomes the 
+loop iterator. Next, the operation Split_Into_Chunks ...
+
+But we still have to describe where the loop parameters are created. Unlike 
+the discrete case, that *can* have side-effects, so your copy of the AARM 
+note is wrong. We can't get away with ignoring that here.
+
+And I don't have a good idea for addressing this. So I'm punting it back to 
+you. :-)
+
+Note that similar issues occur later for the other kinds of iterators, where 
+you inserted "evaluation" rather than "elaboration".
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent