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

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

--- ai12s/ai12-0262-1.txt	2019/01/28 04:47:36	1.10
+++ ai12s/ai12-0262-1.txt	2019/02/05 03:57:20	1.11
@@ -1,4 +1,4 @@
-!standard 4.1.4(1)                                    19-01-17  AI12-0262-1/08
+!standard 4.1.4(1)                                    19-02-01  AI12-0262-1/09
 !standard 4.1.4(6)
 !standard 4.1.4(11)
 !standard 4.5.10(0)
@@ -173,23 +173,23 @@
 
 Modify 4.1.4(6):
 
-In an attribute_reference {that is not a reduction_attribute_reference}, if 
-the attribute_designator is for an attribute defined for (at least some) 
-objects of an access type, then the prefix is never interpreted as an 
+In an attribute_reference {that is not a reduction_attribute_reference}, if
+the attribute_designator is for an attribute defined for (at least some)
+objects of an access type, then the prefix is never interpreted as an
 implicit_dereference; otherwise (and for all range_attribute_references),
-if the type of the name within the prefix is of an access type, the prefix 
-is interpreted as an implicit_dereference. Similarly, if the 
-attribute_designator is for an attribute defined for (at least some) 
-functions, then the prefix is never interpreted as a parameterless 
+if the type of the name within the prefix is of an access type, the prefix
+is interpreted as an implicit_dereference. Similarly, if the
+attribute_designator is for an attribute defined for (at least some)
+functions, then the prefix is never interpreted as a parameterless
 function_call; otherwise (and for all range_attribute_references), if the
-prefix consists of a name that denotes a function, it is interpreted as a 
-parameterless function_call. 
+prefix consists of a name that denotes a function, it is interpreted as a
+parameterless function_call.
 
 Replace 4.1.4(11) with:
 
 The evaluation of a range_attribute_reference or an attribute_reference that
-is not a reduction_attribute_reference consists of the evaluation of the 
-prefix. Redundant[The evaluation of a reduction_attribute_reference is defined 
+is not a reduction_attribute_reference consists of the evaluation of the
+prefix. Redundant[The evaluation of a reduction_attribute_reference is defined
 in 4.5.10.]
 
 
@@ -200,14 +200,15 @@
 Reduction expressions provide a way to map or transform a collection of
 values into a new set of values, and then summarize the values produced by
 applying an operation to reduce the set to a single value result.
-A reduction expression is represented as an attribute_reference of the 
+A reduction expression is represented as an attribute_reference of the
 reduction attribute Reduce.
 
 Syntax
 
 reduction_attribute_reference ::= value_sequence'reduction_attribute_designator
 
-value_sequence ::= '[' [parallel] iterated_component_association ']'
+value_sequence ::=
+  '[' [parallel[(chunk_specification)]] iterated_component_association ']'
 
 reduction_attribute_designator ::= /reduction_/identifier(reduction_specification)
 
@@ -217,21 +218,24 @@
   having a discrete_choice_list, there shall be exactly one
   discrete_choice in the discrete_choice_list, which shall be
   a discrete_subtype_indication or a range.
-  
+
     AARM Reason: If we allow multiple choices, we would have a new
     overload resolution challenge, where you could have multiple
     ranges requiring resolution across them. We disallow single values
-    because that would be useless, and we disallow "others" because there 
-    is no applicable index constraint. The user can use a qualified 
-    expression if they really need to use the full flexibility of 
+    because that would be useless, and we disallow "others" because there
+    is no applicable index constraint. The user can use a qualified
+    expression if they really need to use the full flexibility of
     array-aggregate notation.
 
-    AARM Ramification: There is no rule against discrete_choice_list of a 
-    value_sequence having a discrete_choice that is a subtype_indication or 
-    range that defines a nonstatic or null range. If the choice is a 
-    subtype_indication, the denoted subtype may have a static or
+    AARM Ramification: There is no rule against discrete_choice_list of a
+    value_sequence having a discrete_choice that is a subtype_indication or
+    range that defines a nonstatic or null range. If the choice is a
+    subtype_indication, the denoted subtype might have a static or
     dynamic predicate.
 
+  The chunk_specification, if any, of a value_sequence
+  shall be an /integer_/simple_expression.
+
 Name Resolution Rules
 
 The expected type for a reduction_attribute_reference shall be a single
@@ -247,7 +251,7 @@
    reduction), and Val_Type is short for value type (the type of the input
    values to the reduction).
 
-*  Acc_Type is a subtype of the expected type of the 
+*  Acc_Type is a subtype of the expected type of the
    reduction_attribute_reference.
 
 *  A /reducer subprogram/ is either subtype conformant with the following
@@ -259,7 +263,7 @@
 
       procedure Reducer(Accumulator : in out Acc_Type; Value : in Val_Type);
 
-*  A /combiner subprogram/ is a reducer subprogram where both parameters are 
+*  A /combiner subprogram/ is a reducer subprogram where both parameters are
    of subtype Acc_Type.
 
 *  The /reducer_/name of a reduction_specification denotes a reducer subprogram.
@@ -272,26 +276,26 @@
 *  The expected type of the expression of a value_sequence is that of
    subtype Val_Type.
 
-*  For an iterated_component_association of a value_sequence that has a 
-   discrete_choice_list comprising a single range, the range shall resolve to 
-   some discrete type[Redundant:; which discrete type shall be determined without 
-   using any context other than the bounds of the range itself (plus the 
-   preference for root_integer  see 8.6).].  If the range resolves to 
-   /root_integer/; the type of the index parameter of the 
-   iterated_component_association (the /index type/ of the value_sequence) is 
-   Integer; otherwise the index type is the resolved type of the 
-   discrete_subtype_indication or range of the discrete_choice_list. For an 
-   iterated_component_assocation of a value_sequence that has an 
-   iterator_specification, the /index type/ of the value_sequence is Integer 
-   [Redundant: and the type of the loop parameter of the iterator_specification 
+*  For an iterated_component_association of a value_sequence that has a
+   discrete_choice_list comprising a single range, the range shall resolve to
+   some discrete type[Redundant:; which discrete type shall be determined without
+   using any context other than the bounds of the range itself (plus the
+   preference for root_integer -- see 8.6).].  If the range resolves to
+   /root_integer/; the type of the index parameter of the
+   iterated_component_association (the /index type/ of the value_sequence) is
+   Integer; otherwise the index type is the resolved type of the
+   discrete_subtype_indication or range of the discrete_choice_list. For an
+   iterated_component_assocation of a value_sequence that has an
+   iterator_specification, the /index type/ of the value_sequence is Integer
+   [Redundant: and the type of the loop parameter of the iterator_specification
    is as defined in 5.5.2].
 
 Legality Rules
 
 The combiner_name of a reduction_specification shall be specified
 if the subtypes of the parameters of the subprogram denoted by the
-reducer_Name of the reduction_specification do not statically match each 
-other and the reduction_attribute_reference has a value_sequence with 
+reducer_name of the reduction_specification do not statically match each
+other and the reduction_attribute_reference has a value_sequence with
 the reserved word parallel.
 
 AARM Reason:
@@ -306,7 +310,7 @@
 The nominal subtype of the index parameter of a value_sequence
 is that of the discrete_choice. The nominal subtype of the
 loop parameter of a value_sequence is as defined for an iterator_specification
-(See 5.5.2).
+(see 5.5.2).
 
 A reduction_attribute_reference denotes a value, with nominal subtype
 being the subtype of the first parameter of the reducer subprogram.
@@ -318,21 +322,32 @@
 
 Dynamic Semantics
 
-For the evaluation of a value_sequence, the evaluation proceeds as for a 
-single-dimensional array aggregate (see 4.3.3) with component type being 
-Val_Type and with index type as defined above, with the sequence of values 
-of the value_sequence corresponding to the components of the 
-notional array so defined, in increasing index order.
-
-AARM Discussion:
-The presence of the parallel keyword does not effect the evaluation of
-the value_sequence. Conceptually, a sequential sequence of values is produced,
-as though the parallel keyword were not present.
+For evaluation of a value_sequence:
 
-AARM Implementation Note:
-The intended implementation model is that a value_sequence generally avoids
-producing a temporary object, and instead issue calls to the Reducer as values
-are produced by the evaluation of the value_sequence.
+  * if the iterated_component_association has an iterator_specification, an
+    iteration is performed for that iterator_specification (as described
+    in 5.5.2), and for each value produced by the iterator, the
+    associated expression is evaluated with the loop parameter having
+    this value, to produce a result that is converted to Val_Type, and
+    used to define the next value in the sequence;
+
+  * otherwise, the discrete_choice_list of the iterated_component_association
+    is evaluated, and for each value, in increasing order, of the
+    discrete subtype or range defined by the discrete_choice_list, the
+    associated expression is evaluated with the index parameter having
+    this value, to produce a result that is converted to Val_Type, and
+    used to define the next value in the sequence.
+
+If the value_sequence does not have the reserved word parallel, it is
+produced as a single sequence of values by a single logical thread of
+control. If the reserved word parallel is present in the value_sequence,
+the enclosing reduction_attribute_reference is a parallel construct, and
+the sequence of values is generated by a parallel iteration (as defined
+in 5.5, 5.5.1, and 5.5.2), as a set of non-empty, non-overlapping contiguous
+chunks (/subsequences/) with one logical thread of control (see clause
+9) associated with each subsequence.  If there is a chunk_specification,
+it determines the maximum number of chunks, as defined in 5.5; otherwise
+the maximum number of chunks is implementation defined.
 
 For a value_sequence V, the following attribute is defined:
 
@@ -345,35 +360,35 @@
    begins by evaluating the value_sequence V and the parts of the
    reduction_attribute_designator (the /reducer_/name Reducer, the
    /initial_value_/expression Initial_Value, and the /combiner_/name Combiner,
-   if any), in any order. It then initializes the /accumulator/ of the 
+   if any), in an arbitrary order. It then initializes the /accumulator/ of the
    reduction expression to the value of the /initial_value_/expression (the
-   /initial value/). 
+   /initial value/).
 
    If the value_sequence does not have the reserved word parallel, each
    value of the value_sequence is passed, in order, as the second
    (Value) parameter to a call on Reducer, with the first
    (Accumulator) parameter being the prior value of the accumulator,
    saving the result as the new value of the accumulator. The reduction
-   expression yields the final value of the accumulator. Combiner, if 
+   expression yields the final value of the accumulator. Combiner, if
    specified, is ignored for such a (sequential) reduction expression.
 
    If the reserved word parallel is present in a value_sequence, then
    the (parallel) reduction expression is a parallel construct and the
-   sequence of values is partitioned into one or more contiguous
-   non-empty chunks (/subsequences/), each with its own separate logical
-   thread of control (see clause 9). Each logical thread of control
-   creates a local accumulator for processing its subsequence.  If there
-   is a separate Combiner subprogram specified, then the accumulator for
-   each subsequence is initialized to the initial value, and Reducer
-   is called in sequence order with each value of the subsequence as the
-   second (Value) parameter, and with this local accumulator as the
-   first (Accumulator) parameter, saving the result back into this local
-   accumulator.  If there is no separate combiner specified, then the
-   accumulator for a subsequence is initialized to the first value of
-   the subsequence, and calls on Reducer start with the second value
-   of the subsequence (if any). In either case, the result for the
-   subsequence is the final value of its local accumulator.  
-   
+   sequence has been partitioned into one or more subsequences (see
+   above) each with its own separate logical thread of control.
+
+   Each logical thread of control creates a local accumulator for processing its
+   subsequence. If there is a separate Combiner subprogram specified, then the
+   accumulator for each subsequence is initialized to the initial value, and
+   Reducer is called in sequence order with each value of the subsequence as the
+   second (Value) parameter, and with this local accumulator as the first
+   (Accumulator) parameter, saving the result back into this local accumulator.
+   If there is no separate combiner specified, then the accumulator for a
+   subsequence is initialized to the first value of the subsequence, and calls
+   on Reducer start with the second value of the subsequence (if any). In either
+   case, the result for the subsequence is the final value of its local
+   accumulator.
+
    After all logical threads of control of a parallel reduction
    expression have completed, Combiner (or Reducer, if Combiner is
    not specified) is called for each
@@ -386,7 +401,7 @@
 
    If the evaluation of the value_sequence yields an empty sequence of
    values, the reduction expression yields the initial value.
-   
+
    If an exception is propagated by one of the calls on Reducer or
    Combiner, that exception is propagated from the
    reduction expression. If different exceptions are propagated in
@@ -394,12 +409,12 @@
    propagated from the reduction expression as a whole.
 
 AARM Implementation Note:
-For a reduction_attribute_reference that has a value_sequence without the 
-parallel keyword, generally the compiler can still choose to execute the 
+For a reduction_attribute_reference that has a value_sequence without the
+parallel keyword, generally the compiler can still choose to execute the
 reduction in parallel, presuming doing so would not change the results.
 However, if Combiner is not specified, then sequential
-execution is necessary if the subtypes of the parameters of Reducer do not 
-statically match, since there is no subprogram identified in the construct 
+execution is necessary if the subtypes of the parameters of Reducer do not
+statically match, since there is no subprogram identified in the construct
 that could be used for combining the results in parallel.
 
 AARM Discussion:
@@ -410,9 +425,9 @@
 deterministic result for parallel execution that is consistent with
 sequential execution, we need to specify an order
 for the iteration, and for the combination of results from the logical
-threads of control. It is also necessary that calls to Combiner are issued 
-sequentially with respect to each other, which may require extra 
-synchronization if the calls to Combiner are being executed by different 
+threads of control. It is also necessary that calls to Combiner are issued
+sequentially with respect to each other, which may require extra
+synchronization if the calls to Combiner are being executed by different
 logical threads of control.
 
 Bounded Errors
@@ -426,7 +441,7 @@
   are Program_Error, or a result that does not match the equivalent
   sequential reduction expression due to multiple uses of the
   non-identity initial value in the overall reduction.
-  
+
     AARM Reason: There is no way to do the individual subsequence
     reductions when the Acc_Type and the Val_Type are not the same,
     unless we can initialize the local accumulator with an initial-value
@@ -637,41 +652,41 @@
 !corrigendum 4.1.4(6)
 
 @drepl
-In an @fa<attribute_reference>, if the @fa<attribute_designator> is for an 
-attribute defined for (at least some) objects of an access type, then the 
-@fa<prefix> is never interpreted as an @fa<implicit_dereference>; otherwise 
+In an @fa<attribute_reference>, if the @fa<attribute_designator> is for an
+attribute defined for (at least some) objects of an access type, then the
+@fa<prefix> is never interpreted as an @fa<implicit_dereference>; otherwise
 (and for all @fa<range_attribute_reference>s), if the type of the @fa<name>
-within the @fa<prefix> is of an access type, the @fa<prefix> is interpreted 
+within the @fa<prefix> is of an access type, the @fa<prefix> is interpreted
 as an @fa<implicit_dereference>. Similarly, if the @fa<attribute_designator>
-is for an attribute defined for (at least some) functions, then the 
+is for an attribute defined for (at least some) functions, then the
 @fa<prefix> is never interpreted as a parameterless @fa<function_call>;
 otherwise (and for all @fa<range_attribute_reference>s), if the @fa<prefix>
-consists of a @fa<name> that denotes a function, it is interpreted as a 
-parameterless @fa<function_call>. 
+consists of a @fa<name> that denotes a function, it is interpreted as a
+parameterless @fa<function_call>.
 @dby
-In an @fa<attribute_reference> that is not a 
-@fa<reduction_attribute_reference>, if the @fa<attribute_designator> is for an 
-attribute defined for (at least some) objects of an access type, then the 
-@fa<prefix> is never interpreted as an @fa<implicit_dereference>; otherwise 
-(and for all @fa<range_attribute_reference>s), if the type 
+In an @fa<attribute_reference> that is not a
+@fa<reduction_attribute_reference>, if the @fa<attribute_designator> is for an
+attribute defined for (at least some) objects of an access type, then the
+@fa<prefix> is never interpreted as an @fa<implicit_dereference>; otherwise
+(and for all @fa<range_attribute_reference>s), if the type
 of the @fa<name>
-within the @fa<prefix> is of an access type, the @fa<prefix> is interpreted 
+within the @fa<prefix> is of an access type, the @fa<prefix> is interpreted
 as an @fa<implicit_dereference>. Similarly, if the @fa<attribute_designator>
-is for an attribute defined for (at least some) functions, then the 
+is for an attribute defined for (at least some) functions, then the
 @fa<prefix> is never interpreted as a parameterless @fa<function_call>;
-otherwise (and for all @fa<range_attribute_reference>s), if the 
-@fa<prefix> consists of a @fa<name> that denotes a function, it is 
-interpreted as a parameterless @fa<function_call>. 
+otherwise (and for all @fa<range_attribute_reference>s), if the
+@fa<prefix> consists of a @fa<name> that denotes a function, it is
+interpreted as a parameterless @fa<function_call>.
 
 !corrigendum 4.1.4(11)
 
 @drepl
-The evaluation of an @fa<attribute_reference> (or 
-@fa<range_attribute_reference>) consists of the evaluation of the @fa<prefix>. 
+The evaluation of an @fa<attribute_reference> (or
+@fa<range_attribute_reference>) consists of the evaluation of the @fa<prefix>.
 @dby
-The evaluation of a @fa<range_attribute_reference> or an 
-@fa<attribute_reference> that is not a @fa<reduction_attribute_reference> 
-consists of the evaluation of the @fa<prefix>. The evaluation of a 
+The evaluation of a @fa<range_attribute_reference> or an
+@fa<attribute_reference> that is not a @fa<reduction_attribute_reference>
+consists of the evaluation of the @fa<prefix>. The evaluation of a
 @fa<reduction_attribute_reference> is defined in 4.5.10.
 
 !corrigendum 4.5.10(0)
@@ -1015,21 +1030,21 @@
 
 reduction_expression ::= reduction_attribute_reference
 
-But there is no use of the non-terminal "reduction_expression" anywhere. And 
-since this doesn't do anything at all (it just a "copy production"), I would 
+But there is no use of the non-terminal "reduction_expression" anywhere. And
+since this doesn't do anything at all (it just a "copy production"), I would
 just get rid of it.
 
-Also, you have various wording changes in 4.1.4 that use 
-reduction_attribute_reference. That's a forward reference, and should be 
+Also, you have various wording changes in 4.1.4 that use
+reduction_attribute_reference. That's a forward reference, and should be
 marked as such with a (see 4.5.9) on it's first use.
 
-However, it's usually the case that non-terminals at least appear in some 
-syntax definition before it is used. Thus, I would be happier if 
+However, it's usually the case that non-terminals at least appear in some
+syntax definition before it is used. Thus, I would be happier if
 "reduction_attribute_reference" was used somehow in the syntax of 4.1.4.
 
-"range_attribute_reference" is defined separately because it's not an 
-expression. That's not the case for a reduction_attribute_reference, so it 
-would make sense to put "reduction_attribute_reference" under 
+"range_attribute_reference" is defined separately because it's not an
+expression. That's not the case for a reduction_attribute_reference, so it
+would make sense to put "reduction_attribute_reference" under
 "attribute_reference".
 
 Thus, I would suggest changing the syntax in 4.1.4 to:
@@ -1037,38 +1052,38 @@
     attribute_reference ::= prefix'attribute_designator
        | reduction_attribute_reference
 
-That means that you don't have to make any of the 4.1.4 changes that you have 
-(because reduction_attribute_reference would be automatically included), but 
-some other wording would need to be changed to exclude 
-reduction_attribute_reference. I saw 4.1.4(6) [which talks about 
-"the attribute_designator"] and 4.1.4(11) [which talks about "the prefix"] 
+That means that you don't have to make any of the 4.1.4 changes that you have
+(because reduction_attribute_reference would be automatically included), but
+some other wording would need to be changed to exclude
+reduction_attribute_reference. I saw 4.1.4(6) [which talks about
+"the attribute_designator"] and 4.1.4(11) [which talks about "the prefix"]
 would need to do that. For instance:
 
 Replace 4.1.4(11) with:
 The evaluation of a range_attribute_reference or an attribute_reference that
-is not a reduction_attribute_reference consists of the evaluation of the 
-prefix. Redundant[The evaluation of a reduction_attribute_reference is defined 
+is not a reduction_attribute_reference consists of the evaluation of the
+prefix. Redundant[The evaluation of a reduction_attribute_reference is defined
 in 4.5.9.]
 
 Probably the other would be:
 
-In an attribute_reference {that is not a reduction_attribute_reference}, 
-if the attribute_designator is for an attribute defined for (at least 
+In an attribute_reference {that is not a reduction_attribute_reference},
+if the attribute_designator is for an attribute defined for (at least
 some) objects of an access type, then the prefix is never interpreted as
-an implicit_dereference; otherwise (and for all 
-range_attribute_references{ and reduction_attribute_references}), if {there 
-is a prefix and }the type of the name within the prefix is of an access 
-type, the prefix is interpreted as an implicit_dereference. Similarly, 
-if the attribute_designator is for an attribute defined for (at least some) 
-functions, then the prefix is never interpreted as a parameterless 
-function_call; otherwise (and for all range_attribute_references{ and 
-reduction_attribute_references}), if {there is a prefix and} the prefix 
-consists of a name that denotes a function, it is interpreted as a 
-parameterless function_call. 
-
-[This subsumes the any change for AI12-0242-1 to this paragraph, and the 
-other changes to 4.1.4 listed in that AI aren't needed, either. If we don't 
-do AI12-0242-1, then we only need the first change, as no 
+an implicit_dereference; otherwise (and for all
+range_attribute_references{ and reduction_attribute_references}), if {there
+is a prefix and }the type of the name within the prefix is of an access
+type, the prefix is interpreted as an implicit_dereference. Similarly,
+if the attribute_designator is for an attribute defined for (at least some)
+functions, then the prefix is never interpreted as a parameterless
+function_call; otherwise (and for all range_attribute_references{ and
+reduction_attribute_references}), if {there is a prefix and} the prefix
+consists of a name that denotes a function, it is interpreted as a
+parameterless function_call.
+
+[This subsumes the any change for AI12-0242-1 to this paragraph, and the
+other changes to 4.1.4 listed in that AI aren't needed, either. If we don't
+do AI12-0242-1, then we only need the first change, as no
 reduction_attribute_reference would have a prefix.]
 
 ----------
@@ -1078,47 +1093,47 @@
 Given nonlimited subtypes I and R, where R is a subtype of the expected
 type:
 
-Which expected type? Do you mean the expected type of the 
+Which expected type? Do you mean the expected type of the
 reduction_attribute_reference? If so, say that, don't make me guess.
 
 -------
 
 Typos:
 
-Otherwise{,} the expected type of the loop parameter of a value_sequence is 
+Otherwise{,} the expected type of the loop parameter of a value_sequence is
 as defined for an iterator_specification ({s}[S]ee 5.5.2).
 
 --------
 
-As noted last night, if we say that the reduction is a parallel construct 
-then we don't need anything else here as the checking policy of 9.10.1 
-defines the rules. This is said in the Dynamic Semantics section, but that's 
-rather too late (especially as it's primary effect is on Legality). So I'd 
+As noted last night, if we say that the reduction is a parallel construct
+then we don't need anything else here as the checking policy of 9.10.1
+defines the rules. This is said in the Dynamic Semantics section, but that's
+rather too late (especially as it's primary effect is on Legality). So I'd
 suggest adding that to the start of the Static Semantics section:
 
-A reduction_attribute_reference whose value_sequence includes the reserved 
+A reduction_attribute_reference whose value_sequence includes the reserved
 word parallel is a parallel construct.
 
-And delete the first paragraph of the Legality Rules, because it is dead 
-wrong. (This change lets the checking policy control the rules in this 
+And delete the first paragraph of the Legality Rules, because it is dead
+wrong. (This change lets the checking policy control the rules in this
 construct, like every other parallel construct.)
 
 We can also drop this phrase from the Dynamic Semantics for the attribute.
 
-However, the parallel loop dis defined in Dynamic Semantics, so I suppose 
+However, the parallel loop dis defined in Dynamic Semantics, so I suppose
 it would be OK to just delete the Legality Rule.
 
 --------
 
-The discrete_choice_list of a value_sequence is allowed to have a 
-discrete_choice that is a nonstatic choice_expression or that is a 
+The discrete_choice_list of a value_sequence is allowed to have a
+discrete_choice that is a nonstatic choice_expression or that is a
 subtype_indication or range that defines a nonstatic or null range.
 
-This seems more like an AARM Ramification than a Legality Rule (because it 
+This seems more like an AARM Ramification than a Legality Rule (because it
 doesn't prohibit anything). At most, it should be marked as redundant.
 
-Related to that, you didn't say anything about predicates. Do you mean to 
-allow discontiguous ranges via the use of a predicate? (I don't see a problem, 
+Related to that, you didn't say anything about predicates. Do you mean to
+allow discontiguous ranges via the use of a predicate? (I don't see a problem,
 but it does complicate the implementation.)
 
 That is:
@@ -1128,28 +1143,28 @@
 
         [for I in Odd => I]'Reduce("+", 0)
 
-??? (For more fun, imagine a Dynamic_Predicate being used.) Note that this 
-wouldn't be substantially different than what would happen with a filter 
-(AI12-0250-1), so maybe it's OK. I'd definitely add that to the 
+??? (For more fun, imagine a Dynamic_Predicate being used.) Note that this
+wouldn't be substantially different than what would happen with a filter
+(AI12-0250-1), so maybe it's OK. I'd definitely add that to the
 note/redundant text if intended.
 
 --------
 
-The two AARM notes under Static Semantics seem to relate to parallel 
-execution, which is Dynamic Semantics. Moreover, I don't see the point of 
-the second one (it's an as-if optimization and implementations are always 
-allowed to do those), and the first one is misleading. "sequential execution 
-is presumed" seems to imply something else could happen. I'd at a minimum 
-replace "presumed" by "necessary". And these seem in the wrong order. Maybe 
-mention the possibility of parallel execution anyway at the start of the 
+The two AARM notes under Static Semantics seem to relate to parallel
+execution, which is Dynamic Semantics. Moreover, I don't see the point of
+the second one (it's an as-if optimization and implementations are always
+allowed to do those), and the first one is misleading. "sequential execution
+is presumed" seems to imply something else could happen. I'd at a minimum
+replace "presumed" by "necessary". And these seem in the wrong order. Maybe
+mention the possibility of parallel execution anyway at the start of the
 note with:
 
-For a reduction_attribute_reference that has a value_sequence without the 
-parallel keyword{, generally the compiler can still choose to execute the 
+For a reduction_attribute_reference that has a value_sequence without the
+parallel keyword{, generally the compiler can still choose to execute the
 reduction in parallel, presuming that would not change the results.
-However,} if the combiner ... 
+However,} if the combiner ...
 
-Then the second note is unneeded. We surely don't need to go into detail about 
+Then the second note is unneeded. We surely don't need to go into detail about
 what is and is not allowed unless it is somehow different than the usual.
 
 ---------
@@ -1166,13 +1181,13 @@
 
 -----
 
-The AARM Note at the end of the Dynamic Semantics section appears to say 
+The AARM Note at the end of the Dynamic Semantics section appears to say
 essentially the same thing twice. Can these be combined??
 
 -----
 
-That's it for the !wording. Note that I didn't try to figure out if this does 
-the right thing (I barely know what that is :-), but just that the wording 
+That's it for the !wording. Note that I didn't try to figure out if this does
+the right thing (I barely know what that is :-), but just that the wording
 organization made sense.
 
 ****************************************************************
@@ -1182,57 +1197,57 @@
 
 Under Name Resolution Rules for AI12-0262-1, we have the following rule:
 
-  The expected type for a value_sequence shall be a single one-dimensional 
-  array type. The component type of this array type is the expected type of 
+  The expected type for a value_sequence shall be a single one-dimensional
+  array type. The component type of this array type is the expected type of
   the index parameter or loop parameter for the value_sequence.
 
-This cannot be what we want. As written, this requires an actual type 
-somewhere in the program's universe with these characteristics. Moreover, 
-we wanted to allow cases where an actual array could not be declared (the 
-component type being indefinite, such as T'Class). This rule doesn't allow 
+This cannot be what we want. As written, this requires an actual type
+somewhere in the program's universe with these characteristics. Moreover,
+we wanted to allow cases where an actual array could not be declared (the
+component type being indefinite, such as T'Class). This rule doesn't allow
 that.
 
-Probably what Brad (or someone) was thinking is that we need a nominal array 
+Probably what Brad (or someone) was thinking is that we need a nominal array
 type so that we can reuse the array aggregate dynamic semantics for describing
-how a value_sequence is evaluated. But we don't want to describe that as a 
+how a value_sequence is evaluated. But we don't want to describe that as a
 "Name Resolution Rule".
 
-(Side note: The description above is wrong, too: the component type needs to 
-be "I", the type of the value being reduced. It doesn't have anything to do 
+(Side note: The description above is wrong, too: the component type needs to
+be "I", the type of the value being reduced. It doesn't have anything to do
 with the index/loop parameter.)
 
-I think it probably would be best to simply define this imaginary array type 
+I think it probably would be best to simply define this imaginary array type
 in the one place that it matters, and that is the Dynamic Semantics. The only
 problem is the "I", the type of the component, is defined a long ways away. It
-probably would be better if "I" and "R" had real names. Maybe "reduction 
+probably would be better if "I" and "R" had real names. Maybe "reduction
 component type" and "reduction result type"???
 
-Anyway, we need a rule at the top of the Dynamic Semantics section to give 
+Anyway, we need a rule at the top of the Dynamic Semantics section to give
 this phony array definition:
 
-  For the purposes of evaluation of a reduction expression, a value_sequence 
-  is presumed to be of a one-dimensional array type with a component type of 
-  I (<better name here>). The index subtype is that of the discrete_range if 
+  For the purposes of evaluation of a reduction expression, a value_sequence
+  is presumed to be of a one-dimensional array type with a component type of
+  I (<better name here>). The index subtype is that of the discrete_range if
   present, and Standard.Integer otherwise.
 
-AARM Discussion: We use this type only for purposes of describing the 
-evaluation of the value_sequence. There does not need to be any type with 
-these characteristics available in the program. Indeed, if I is an indefinite 
+AARM Discussion: We use this type only for purposes of describing the
+evaluation of the value_sequence. There does not need to be any type with
+these characteristics available in the program. Indeed, if I is an indefinite
 type, one cannot even declare such a type.
 
 AARM To Be Honest: The index subtype is chosen to avoid any check failures.
-But there is no intent to check that the aggregate determined would fit in 
+But there is no intent to check that the aggregate determined would fit in
 the index subtype; that might matter on a system with Integer'Last = 2**15-1.
 
-We might want to consider splitting up the current the first paragraph to 
-include this information in the wording for evaluating the value_sequence, 
+We might want to consider splitting up the current the first paragraph to
+include this information in the wording for evaluating the value_sequence,
 rather than putting it before everything else.
 
-Anyway, does this make sense? Are there any better ideas of how to define the 
-evaluation of the value_sequence? (doing that exclusively here seems 
+Anyway, does this make sense? Are there any better ideas of how to define the
+evaluation of the value_sequence? (doing that exclusively here seems
 unappealing, as a number of rules would have to be copied).
 
-P.S. I suggest fixing this in a clean-up AI. Have no interest in reopening 
+P.S. I suggest fixing this in a clean-up AI. Have no interest in reopening
 this AI. :-)
 
 ****************************************************************
@@ -1241,70 +1256,70 @@
 Sent: Wednesday, January 16, 2019  1:01 PM
 
 > Under Name Resolution Rules for AI12-0262-1, we have the following rule:
-> 
->  The expected type for a value_sequence shall be a single 
-> one-dimensional array  type. The component type of this array type is 
-> the expected type of the index  parameter or loop parameter for the 
+>
+>  The expected type for a value_sequence shall be a single
+> one-dimensional array  type. The component type of this array type is
+> the expected type of the index  parameter or loop parameter for the
 > value_sequence.
-> 
-> This cannot be what we want. As written, this requires an actual type 
-> somewhere in the program's universe with these characteristics. 
-> Moreover, we wanted to allow cases where an actual array could not be 
-> declared (the component type being indefinite, such as T'Class). This 
+>
+> This cannot be what we want. As written, this requires an actual type
+> somewhere in the program's universe with these characteristics.
+> Moreover, we wanted to allow cases where an actual array could not be
+> declared (the component type being indefinite, such as T'Class). This
 > rule doesn't allow that.
 
-Good point.  One of the whole goals of the reduction expression is to do a 
-reduction without ever "actualizing" such an array, and without having to 
+Good point.  One of the whole goals of the reduction expression is to do a
+reduction without ever "actualizing" such an array, and without having to
 declare such an array type.  A value sequence doesn't have a type, or if it
 does, it is an anonymous array type.
- 
-> Probably what Brad (or someone) was thinking is that we need a nominal 
-> array type so that we can reuse the array aggregate dynamic semantics 
-> for describing how a value_sequence is evaluated. But we don't want to 
+
+> Probably what Brad (or someone) was thinking is that we need a nominal
+> array type so that we can reuse the array aggregate dynamic semantics
+> for describing how a value_sequence is evaluated. But we don't want to
 > describe that as a "Name Resolution Rule".
-> 
-> (Side note: The description above is wrong, too: the component type 
-> needs to be "I", the type of the value being reduced. It doesn't have 
+>
+> (Side note: The description above is wrong, too: the component type
+> needs to be "I", the type of the value being reduced. It doesn't have
 > anything to do with the index/loop parameter.)
-> 
-> I think it probably would be best to simply define this imaginary 
-> array type in the one place that it matters, and that is the Dynamic 
-> Semantics. The only problem is the "I", the type of the component, is 
-> defined a long ways away. It probably would be better if "I" and "R" 
-> had real names. Maybe "reduction component type" and "reduction result 
+>
+> I think it probably would be best to simply define this imaginary
+> array type in the one place that it matters, and that is the Dynamic
+> Semantics. The only problem is the "I", the type of the component, is
+> defined a long ways away. It probably would be better if "I" and "R"
+> had real names. Maybe "reduction component type" and "reduction result
 > type"???
-> 
-> Anyway, we need a rule at the top of the Dynamic Semantics section to 
+>
+> Anyway, we need a rule at the top of the Dynamic Semantics section to
 > give this phony array definition:
-> 
->     For the purposes of evaluation of a reduction expression, a 
-> value_sequence is presumed to be of a one-dimensional array type with 
-> a component type of I (<better name here>). The index subtype is that 
+>
+>     For the purposes of evaluation of a reduction expression, a
+> value_sequence is presumed to be of a one-dimensional array type with
+> a component type of I (<better name here>). The index subtype is that
 > of the discrete_range if present, and Standard.Integer otherwise.
-> 
-> AARM Discussion: We use this type only for purposes of describing the 
-> evaluation of the value_sequence. There does not need to be any type 
-> with these characteristics available in the program. Indeed, if I is 
+>
+> AARM Discussion: We use this type only for purposes of describing the
+> evaluation of the value_sequence. There does not need to be any type
+> with these characteristics available in the program. Indeed, if I is
 > an indefinite type, one cannot even declare such a type.
-> 
+>
 > AARM To Be Honest: The index subtype is chosen to avoid any check failures.
-> But there is no intent to check that the aggregate determined would 
-> fit in the index subtype; that might matter on a system with 
+> But there is no intent to check that the aggregate determined would
+> fit in the index subtype; that might matter on a system with
 > Integer'Last = 2**15-1.
-> 
-> We might want to consider splitting up the current the first paragraph 
-> to include this information in the wording for evaluating the 
+>
+> We might want to consider splitting up the current the first paragraph
+> to include this information in the wording for evaluating the
 > value_sequence, rather than putting it before everything else.
-> 
-> Anyway, does this make sense? Are there any better ideas of how to 
-> define the evaluation of the value_sequence? (doing that exclusively 
+>
+> Anyway, does this make sense? Are there any better ideas of how to
+> define the evaluation of the value_sequence? (doing that exclusively
 > here seems unappealing, as a number of rules would have to be copied).
 
-This seems like a lot of horsing around for no clear reason.  I suggest we 
-adjust the wording a bit so we don't need to talk about this array type at 
+This seems like a lot of horsing around for no clear reason.  I suggest we
+adjust the wording a bit so we don't need to talk about this array type at
 all.  Let me give it a shot.  (I'll try to send something shortly.)
 
-> P.S. I suggest fixing this in a clean-up AI. Have no interest in 
+> P.S. I suggest fixing this in a clean-up AI. Have no interest in
 > reopening this AI. :-)
 
 Agreed.
@@ -1312,17 +1327,17 @@
 I also noticed a problem with the "NOTES" at the bottom:
 
 * The Initial_Value of a reduction expression is only evaluated once.
-* The /reducer_/subprogram and the /combiner_/subprogram /potentially 
+* The /reducer_/subprogram and the /combiner_/subprogram /potentially
   conflict/ with other actions.
 
-The first bullet has a number of problems, and might be best eliminated.  
+The first bullet has a number of problems, and might be best eliminated.
 But if we wanted to get it exactly right:
-* The evaluation of a reduction expression includes exactly one evaluation of 
+* The evaluation of a reduction expression includes exactly one evaluation of
   the Initial_Value expression.
 
-The second bullet is very confusing, as it is "actions", not "subprograms," 
-that potentially conflict.  If it is non-normative, I suggest we remove it, 
-as it would be more confusing than clarifying for most users, I would guess. 
+The second bullet is very confusing, as it is "actions", not "subprograms,"
+that potentially conflict.  If it is non-normative, I suggest we remove it,
+as it would be more confusing than clarifying for most users, I would guess.
 If it is normative, it doesn't belong in a NOTE.  But I hope it is implied by
 the dynamic semantics, and so should probably just be dropped.
 
@@ -1331,18 +1346,18 @@
 From: Steve Baird
 Sent: Wednesday, January 16, 2019  1:30 PM
 
-> One of the whole goals of the reduction expression is to do a reduction 
-> without ever "actualizing" such an array, and without having to declare 
+> One of the whole goals of the reduction expression is to do a reduction
+> without ever "actualizing" such an array, and without having to declare
 > such an array type.  A value sequence doesn't have a type, or if it does,
 > it is an anonymous array type.
 
-If we want to preserve the wording (and perhaps we don't) defining the 
-dynamic semantics of evaluating a sequence in terms of evaluation of an 
-array aggregate, then it seems like we need some notional anonymous array 
-type. In particular, the component subtype of this notional array type would 
-need to be defined and, unlike "real" array types, that subtype might be 
-indefinite (e.g., for the case where the value sequence is a sequence of 
-values of a class-wide type, or where it is a sequence of array values having 
+If we want to preserve the wording (and perhaps we don't) defining the
+dynamic semantics of evaluating a sequence in terms of evaluation of an
+array aggregate, then it seems like we need some notional anonymous array
+type. In particular, the component subtype of this notional array type would
+need to be defined and, unlike "real" array types, that subtype might be
+indefinite (e.g., for the case where the value sequence is a sequence of
+values of a class-wide type, or where it is a sequence of array values having
 differing lengths).
 
 ****************************************************************
@@ -1350,10 +1365,10 @@
 From: Randy Brukardt
 Sent: Wednesday, January 16, 2019  1:57 PM
 
-Right. Defining a notional array type is what I was trying to do with my 
-suggested wording. Otherwise, we'd have to define the semantics of evaluating 
-the value sequence here, and stop describing it as an array aggregate (which 
-happens in a variety of places). That in fact would be my preference if it 
+Right. Defining a notional array type is what I was trying to do with my
+suggested wording. Otherwise, we'd have to define the semantics of evaluating
+the value sequence here, and stop describing it as an array aggregate (which
+happens in a variety of places). That in fact would be my preference if it
 is short enough, but that's a large IF.
 
 ****************************************************************
@@ -1361,7 +1376,7 @@
 From: Edmond Schonberg
 Sent: Wednesday, January 16, 2019  2:08 PM
 
-Now that we have container aggregates, it might be simpler to relate the 
+Now that we have container aggregates, it might be simpler to relate the
 sequence to the construction of a list container, so the index is unrelated
 to any index type of that notional anonymous array type.
 
@@ -1370,7 +1385,7 @@
 From: Tucker Taft
 Sent: Wednesday, January 16, 2019  5:12 PM
 
-The proposed dynamic semantics for parallel reduction don't seem to work if 
+The proposed dynamic semantics for parallel reduction don't seem to work if
 the value type ("I") and the accumulator type ("R") are different:
 
    "... If the reserved word parallel is
@@ -1381,36 +1396,36 @@
    result of its iteration, which is initialized to the value of the expression
    produced by the first assigned iteration."
 
-Some of this terminology I believe could be improved, but in any case, the 
-"first assigned iteration" is the first value in the chunk of values assigned 
-to the logical thread of control, and that is of the "value" type ("I").  But 
-the final result of a reduction expression is supposed to be of the 
-"accumulator" type ("R").  So this doesn't work as written.  I think we need 
+Some of this terminology I believe could be improved, but in any case, the
+"first assigned iteration" is the first value in the chunk of values assigned
+to the logical thread of control, and that is of the "value" type ("I").  But
+the final result of a reduction expression is supposed to be of the
+"accumulator" type ("R").  So this doesn't work as written.  I think we need
 to use the value of the initial-value expression even in a parallel reduction,
 since that has the right type (namely, the accumulator type).  I realize there
 are some down sides to that, since it means the initial value really needs to
 be the identity of the reduction, so we need to make that very clear.  For the
 sequential reduction, the initial value can be arbitrary.
 
-Note that if the two parameter subtypes to the reducer are the same, then the 
-above description works OK (i.e. accumulator and value types are the same).  
-We could say that if there is a combiner specified for a parallel reduction, 
-then the initial-value expression needs to be the identity of the reducer (and 
-the combiner, presumably!).  If no combiner is specified, the initial-value 
-need not be an identity of the reducer, since we can use the "trick" used 
-above, where the first value of each chunk is the starting value for the 
-accumulator.  But again, this only works if the values and the accumulator(s) 
-are of the same type.  
+Note that if the two parameter subtypes to the reducer are the same, then the
+above description works OK (i.e. accumulator and value types are the same).
+We could say that if there is a combiner specified for a parallel reduction,
+then the initial-value expression needs to be the identity of the reducer (and
+the combiner, presumably!).  If no combiner is specified, the initial-value
+need not be an identity of the reducer, since we can use the "trick" used
+above, where the first value of each chunk is the starting value for the
+accumulator.  But again, this only works if the values and the accumulator(s)
+are of the same type.
 
-Note that in this latter case, it is important that the initial-value 
-expression *is* used in the final sequence of calls combining all of the 
+Note that in this latter case, it is important that the initial-value
+expression *is* used in the final sequence of calls combining all of the
 individual chunk accumulators into the final result.
 
-Unless someone objects, I'll go with this last idea in my "fixup" work on 
-this AI, where if there is a separate combiner specified, we make it a 
-bounded error if the initial-value is not an identity for both reducer and 
+Unless someone objects, I'll go with this last idea in my "fixup" work on
+this AI, where if there is a separate combiner specified, we make it a
+bounded error if the initial-value is not an identity for both reducer and
 combiner.  If there is no combiner specified, then the initial-value will be
-included in the overall reduction exactly once, just as it is in the 
+included in the overall reduction exactly once, just as it is in the
 sequential reduction.
 
 ****************************************************************
@@ -1418,14 +1433,14 @@
 From: Randy Brukardt
 Sent: Wednesday, January 16, 2019  5:41 PM
 
-> The proposed dynamic semantics for parallel reduction don't seem to 
+> The proposed dynamic semantics for parallel reduction don't seem to
 > work if the value type ("I") and the accumulator type
 > ("R") are different:
 
 I think I follow your argument, and it makes sense to me.
 
-BTW, can we give these types real names? I and R don't make a lot of sense 
-in rules a page down from the definition. "Value type" and "accumulator 
+BTW, can we give these types real names? I and R don't make a lot of sense
+in rules a page down from the definition. "Value type" and "accumulator
 type" also help motivate what is going on.
 
 ****************************************************************
@@ -1433,28 +1448,28 @@
 From: Brad Moore
 Sent: Wednesday, January 16, 2019  8:04 PM
 
-> Unless someone objects, I'll go with this last idea in my "fixup" work 
-> on this AI, where if there is a separate combiner specified, we make 
-> it a bounded error if the initial-value is not an identity for both 
-> reducer and combiner.  If there is no combiner specified, then the 
-> initial-value will be included in the overall reduction exactly once, 
+> Unless someone objects, I'll go with this last idea in my "fixup" work
+> on this AI, where if there is a separate combiner specified, we make
+> it a bounded error if the initial-value is not an identity for both
+> reducer and combiner.  If there is no combiner specified, then the
+> initial-value will be included in the overall reduction exactly once,
 > just as it is in the sequential reduction.
 
-Agreed, with all you have said... 
+Agreed, with all you have said...
 
 ****************************************************************
 
 From: Tucker Taft
 Sent: Wednesday, January 16, 2019  7:39 PM
 
-Here is an attempt to address the problems identified earlier, as well as 
-several others that Randy and others have noticed.  I purposely did *not* 
+Here is an attempt to address the problems identified earlier, as well as
+several others that Randy and others have noticed.  I purposely did *not*
 introduce the chunk-specification syntax into this, as I believe we agreed
 that that will be a separate AI.  I made the last-minute switch from "I" and
 "R" to "Val_Type" and "Acc_Type" as suggested in this e-mail from Randy.
 
-> BTW, can we give these types real names? I and R don't make a lot of 
-> sense in rules a page down from the definition. "Value type" and 
+> BTW, can we give these types real names? I and R don't make a lot of
+> sense in rules a page down from the definition. "Value type" and
 > "accumulator type" also help motivate what is going on.
 
 ---------
@@ -1465,10 +1480,10 @@
 
 Modify the introduction, as follows:
 
-Reduction expressions provide[s] a way to map or transform a collection of 
-values into a new set of values, and then summarize the values produced by 
-applying an operation to reduce the set to a single [value] result.  {A 
-reduction expression is represented as a reference to the reduction 
+Reduction expressions provide[s] a way to map or transform a collection of
+values into a new set of values, and then summarize the values produced by
+applying an operation to reduce the set to a single [value] result.  {A
+reduction expression is represented as a reference to the reduction
 attribute Reduce.}
 
 -------
@@ -1479,7 +1494,7 @@
   having a discrete_choice_list, there shall be exactly one
   discrete_choice in the discrete_choice_list, which shall be
   a discrete_subtype_indication or a range.
-  
+
     AARM Reason: If we allow multiple choices, we would have a new
     overload resolution challenge, where you could have multiple
     ranges requiring resolution across them.  We disallow single values
@@ -1487,47 +1502,47 @@
     there is no applicable index constraint.  The user can use a
     qualified expression if they really need to use the full flexibility
     of array-aggregate notation.
-    
+
 ---
-  
+
 Name Resolution
 
-Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on a 
+Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on a
 suggestion by Randy).
 
 ...
 
 Modify the following paragraph, as follows:
 
-A /combiner_/subprogram is a /reducer_/subprogram where [subtypes I and R 
+A /combiner_/subprogram is a /reducer_/subprogram where [subtypes I and R
 statically match] {both parameters are of subtype Acc_Type}.
 
 ...
 
 Replace the last two paragraphs of Name Resolution, which are currently:
 
-The expected type of the index parameter of a value_sequence is that of the 
-discrete_choice. Otherwise, the expected type of the loop parameter of a 
+The expected type of the index parameter of a value_sequence is that of the
+discrete_choice. Otherwise, the expected type of the loop parameter of a
 value_sequence is as defined for an iterator_specification (see 5.5.2).
 
-The expected type for a value_sequence shall be a single one-dimensional 
-array type. The component type of this array type is the expected type of the 
+The expected type for a value_sequence shall be a single one-dimensional
+array type. The component type of this array type is the expected type of the
 index parameter or loop parameter for the value_sequence.
 
 with:
 
-For an iterated_component_association of a value_sequence that has a 
-discrete_choice_list comprising a single range, the range shall resolve to 
-some discrete type[Redundant:; which discrete type shall be determined without 
-using any context other than the bounds of the range itself (plus the 
-preference for root_integer  see 8.6).].  If the range resolves to 
-/root_integer/; the type of the index parameter of the 
-iterated_component_association (the /index type/ of the value_sequence) is 
-Integer; otherwise the index type is the resolved type of the 
-discrete_subtype_indication or range of the discrete_choice_list. For an 
-iterated_component_assocation of a value_sequence that has an 
-iterator_specification, the /index type/ of the value_sequence is Integer 
-[Redundant: and the type of the loop parameter of the 
+For an iterated_component_association of a value_sequence that has a
+discrete_choice_list comprising a single range, the range shall resolve to
+some discrete type[Redundant:; which discrete type shall be determined without
+using any context other than the bounds of the range itself (plus the
+preference for root_integer  see 8.6).].  If the range resolves to
+/root_integer/; the type of the index parameter of the
+iterated_component_association (the /index type/ of the value_sequence) is
+Integer; otherwise the index type is the resolved type of the
+discrete_subtype_indication or range of the discrete_choice_list. For an
+iterated_component_assocation of a value_sequence that has an
+iterator_specification, the /index type/ of the value_sequence is Integer
+[Redundant: and the type of the loop parameter of the
 iterator_specification is as defined in 5.2.2].
 
 ---
@@ -1539,16 +1554,16 @@
 Dynamic Semantics
 
 For a reduction_attribute_reference, the value_sequence is first evaluated.
-For a value_sequence with or without the reserved word parallel, the 
-evaluation of a value_sequence is as defined for an array aggregate 
+For a value_sequence with or without the reserved word parallel, the
+evaluation of a value_sequence is as defined for an array aggregate
 (see 4.3.3). The reduction_attribute_designator is then evaluated.
 
 with:
 
 Dynamic Semantics
 
-For the evaluation of a value_sequence, the evaluation proceeds as for a 
-single-dimensional array aggregate (see 4.3.3) with component type being 
+For the evaluation of a value_sequence, the evaluation proceeds as for a
+single-dimensional array aggregate (see 4.3.3) with component type being
 Val_Type and with index type as defined above, with the sequence of values
 of the value_sequence corresponding to the components of the notional array
 so defined, in increasing index order.
@@ -1566,7 +1581,7 @@
    /initial_value_/expression, and the /combiner_/name (if any), in any
    order. It then initializes the /accumulator/ of the reduction
    expression to the value of the /initial_value_/expression (the
-   /initial value/). 
+   /initial value/).
 
    If the value_sequence does not have the reserved word parallel, each
    value of the value_sequence is passed, in order, as the second
@@ -1592,8 +1607,8 @@
    accumulator for a subsequence is initialized to the first value of
    the subsequence, and calls on the reducer start with the second value
    of the subsequence (if any).  In either case, the result for the
-   subsequence is the final value of its local accumulator.  
-   
+   subsequence is the final value of its local accumulator.
+
    After all logical threads of control of a parallel reduction
    expression have completed, the combiner is called for each
    subsequence, in the original sequence order, passing the local
@@ -1609,13 +1624,13 @@
 
    If the evaluation of the value_sequence yields an empty sequence of
    values, the reduction expression yields the initial value.
-   
+
    If an exception is propagated by one of the calls on the reducer or
    combiner subprogram, that exception is propagated from the
    reduction expression.  If different exceptions are propagated in
    different logical threads of control, one is chosen arbitrarily to be
    propagated from the reduction expression as a whole.
-   
+
 ---
 
 Add the following:
@@ -1631,7 +1646,7 @@
   are Program_Error, or a result that does not match the equivalent
   sequential reduction expression due to multiple uses of the
   non-identity initial value in the overall reduction.
-  
+
     AARM Reason: There is no way to do the individual subsequence
     reductions when the Acc_Type and the Val_Type are not the same,
     unless we can initialize the local accumulator with an initial-value
@@ -1648,7 +1663,7 @@
 
 ---
 
-Delete the two NOTES as they have some wording issues, and are probably not 
+Delete the two NOTES as they have some wording issues, and are probably not
 that helpful.
 
 ****************************************************************
@@ -1658,40 +1673,40 @@
 
 > Here is an attempt to address the problems ...
 
-Thanks for doing this. When can I get your homework, similar wording changes 
+Thanks for doing this. When can I get your homework, similar wording changes
 to AI12-0266-1? :-)
 
 > Modify the introduction, as follows:
-> 
-> Reduction expressions provide[s] a way to map or transform a 
-> collection of values into a new set of values, and then summarize the 
-> values produced by applying an operation to reduce the set to a single 
-> [value] result.  {A reduction expression is represented as a reference 
+>
+> Reduction expressions provide[s] a way to map or transform a
+> collection of values into a new set of values, and then summarize the
+> values produced by applying an operation to reduce the set to a single
+> [value] result.  {A reduction expression is represented as a reference
 > to the reduction attribute Reduce.}
 
-"reference" here strikes me as strange. Either is just a use of the attribute, 
-or it is an attribute_reference. I changed the text to use the latter, since 
+"reference" here strikes me as strange. Either is just a use of the attribute,
+or it is an attribute_reference. I changed the text to use the latter, since
 that was the change agreed upon during the meeting.
 
-I also note that this wording needs to be changed further to take AI12-0242-1 
+I also note that this wording needs to be changed further to take AI12-0242-1
 into account, which defines a Parallel_Reduce attribute.
 
 So, I ultimately used:
-A reduction expression is represented as an attribute_reference of the 
+A reduction expression is represented as an attribute_reference of the
 reduction attributes Reduce or Parallel_Reduce.
 
 [For AI12-0262-1 individually, I dropped the Parallel_Reduce part.]
 
 >Add the following immediately after the BNF (within the Syntax Rules section):
 >
->  For the case of an iterated_component_association of a value_sequence  
-> having a discrete_choice_list, there shall be exactly one  
-> discrete_choice in the discrete_choice_list, which shall be  a 
+>  For the case of an iterated_component_association of a value_sequence
+> having a discrete_choice_list, there shall be exactly one
+> discrete_choice in the discrete_choice_list, which shall be  a
 > discrete_subtype_indication or a range.
 
 I presume you want to delete the Legality Rule that said essentially this.
 There's no point in having both. That forced me to move the AARM Note about
-dynamic choices to the Syntax section. It doesn't really belong there, but 
+dynamic choices to the Syntax section. It doesn't really belong there, but
 it makes no sense floating in Legality Rules with no related text.
 
 >     AARM Reason: If we allow multiple choices, we would have a new
@@ -1702,24 +1717,24 @@
 >     qualified expression if they really need to use the full flexibility
 >     of array-aggregate notation.
 
-We can do better than "weird". I used "useless". I wanted to use "only useful 
+We can do better than "weird". I used "useless". I wanted to use "only useful
 for an obfuscated code contest", 'cause I was thinking about:
 
    [for I in 1 => I]'Reduce ("+", A)
 
 which is a really complicated way to add 1 to A. Of course, we still allow:
- 
+
    [for I in 0..1 => I]'Reduce ("+", A)
 
-which is an even more complicated way to add 1 to A. So I just settled on 
+which is an even more complicated way to add 1 to A. So I just settled on
 "useless". :-)
 
 
 > ---
->   
+>
 > Name Resolution
-> 
-> Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on a 
+>
+> Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on a
 > suggestion by Randy).
 
 I added a short AARM note to this:
@@ -1728,68 +1743,68 @@
    reduction), and Val_Type is short for value type (the type of the input
    values to the reduction).
 
-I could see making something like this NOTE, except that notes are all at the 
+I could see making something like this NOTE, except that notes are all at the
 bottom when its far too late for these to do any good.
 
 > ---
-> 
+>
 > Dynamic Semantics
-> 
+>
 > Replace the following:
-> 
+>
 > Dynamic Semantics
-> 
-> For a reduction_attribute_reference, the value_sequence is first 
+>
+> For a reduction_attribute_reference, the value_sequence is first
 > evaluated.
-> For a value_sequence with or without the reserved word parallel, the 
-> evaluation of a value_sequence is as defined for an array aggregate 
+> For a value_sequence with or without the reserved word parallel, the
+> evaluation of a value_sequence is as defined for an array aggregate
 > (see 4.3.3).
 > The reduction_attribute_designator is then evaluated.
-> 
+>
 > with:
-> 
+>
 > Dynamic Semantics
-> 
-> For the evaluation of a value_sequence, the evaluation proceeds as for 
+>
+> For the evaluation of a value_sequence, the evaluation proceeds as for
 > a single-dimensional array aggregate (see
-> 4.3.3) with component type being Val_Type and with index type as 
-> defined above, with the sequence of values of the value_sequence 
-> corresponding to the components of the notional array so defined, in 
+> 4.3.3) with component type being Val_Type and with index type as
+> defined above, with the sequence of values of the value_sequence
+> corresponding to the components of the notional array so defined, in
 > increasing index order.
 
-You didn't edit the following AARM notes. I tried to scrub the discussion 
-of "array aggregate" from them while leaving the gist. 
+You didn't edit the following AARM notes. I tried to scrub the discussion
+of "array aggregate" from them while leaving the gist.
 
 AARM Discussion:
-The presence of the parallel keyword does not effect the evaluation of the 
-value_sequence. Conceptually, a sequential sequence of values is produced, 
+The presence of the parallel keyword does not effect the evaluation of the
+value_sequence. Conceptually, a sequential sequence of values is produced,
 as though the parallel keyword were not present.
 
 AARM Implementation Note:
-The intended implementation model is that a value_sequence generally avoids 
-producing a temporary object, and instead issue calls to the Reducer as 
+The intended implementation model is that a value_sequence generally avoids
+producing a temporary object, and instead issue calls to the Reducer as
 values are produced by the evaluation of the value_sequence.
 
-You might have intended to remove the first AARM note completely - I couldn't 
-tell since you didn't mention them at all. (I don't think the first one says 
-much interesting, and in some sense it is wrong, since the evaluation is 
-likely to be different, at least at the generated code level, if the reduction 
-is parallel. Esp. if we have a container iterator.) The second note definitely 
-has value, since we want to say that even though this evaluated roughly like 
+You might have intended to remove the first AARM note completely - I couldn't
+tell since you didn't mention them at all. (I don't think the first one says
+much interesting, and in some sense it is wrong, since the evaluation is
+likely to be different, at least at the generated code level, if the reduction
+is parallel. Esp. if we have a container iterator.) The second note definitely
+has value, since we want to say that even though this evaluated roughly like
 an aggregate, we're not expecting an object to be created by the evaluation.
 
 > ---
-> 
-> Replace the paragraphs defining the V'Reduce attribute with the 
+>
+> Replace the paragraphs defining the V'Reduce attribute with the
 > following:
-> 
+>
 > The following attribute is defined for a value_sequence V:
-> 
+>
 > V'Reduce (/reducer_/name, /initial_value_/expression[,
 > /combiner_/name])
 ...
 
-I assumed that you were leaving the AARM notes alone. They still seem relevant 
+I assumed that you were leaving the AARM notes alone. They still seem relevant
 (although you might have simplified some of the wording had you edited them).
 
 
@@ -1802,58 +1817,58 @@
 Sent: Friday, January 18, 2019  9:41 AM
 
 >> Here is an attempt to address the problems ...
-> 
-> Thanks for doing this. When can I get your homework, similar wording 
+>
+> Thanks for doing this. When can I get your homework, similar wording
 > changes to AI12-0266-1? :-)
 
 I'll try to do this today.
 
-> 
+>
 >> Modify the introduction, as follows:
->> 
->> Reduction expressions provide[s] a way to map or transform a 
->> collection of values into a new set of values, and then summarize the 
->> values produced by applying an operation to reduce the set to a 
->> single [value] result.  {A reduction expression is represented as a 
+>>
+>> Reduction expressions provide[s] a way to map or transform a
+>> collection of values into a new set of values, and then summarize the
+>> values produced by applying an operation to reduce the set to a
+>> single [value] result.  {A reduction expression is represented as a
 >> reference to the reduction attribute Reduce.}
-> 
-> "reference" here strikes me as strange. Either is just a use of the 
-> attribute, or it is an attribute_reference. I changed the text to use 
+>
+> "reference" here strikes me as strange. Either is just a use of the
+> attribute, or it is an attribute_reference. I changed the text to use
 > the latter, since that was the change agreed upon during the meeting.
 
-I presumed in an informal introduction, you could say "reference an attribute" 
-as equivalent to "make an attribute_reference," but I am fine if you want to 
+I presumed in an informal introduction, you could say "reference an attribute"
+as equivalent to "make an attribute_reference," but I am fine if you want to
 formalize the wording further.
- 
+
 > I also note that this wording needs to be changed further to take
 > AI12-0242-1 into account, which defines a Parallel_Reduce attribute.
-> 
+>
 > So, I ultimately used:
-> A reduction expression is represented as an attribute_reference of the 
+> A reduction expression is represented as an attribute_reference of the
 > reduction attributes Reduce or Parallel_Reduce.
 
 OK.
 
 > [For AI12-0262-1 individually, I dropped the Parallel_Reduce part.]
-> 
+>
 >> Add the following immediately after the BNF (within the Syntax Rules
 > section):
->> 
->> For the case of an iterated_component_association of a value_sequence 
->> having a discrete_choice_list, there shall be exactly one 
->> discrete_choice in the discrete_choice_list, which shall be a 
+>>
+>> For the case of an iterated_component_association of a value_sequence
+>> having a discrete_choice_list, there shall be exactly one
+>> discrete_choice in the discrete_choice_list, which shall be a
 >> discrete_subtype_indication or a range.
-> 
+>
 > I presume you want to delete the Legality Rule that said essentially this.
-> There's no point in having both. That forced me to move the AARM Note 
-> about dynamic choices to the Syntax section. It doesn't really belong 
+> There's no point in having both. That forced me to move the AARM Note
+> about dynamic choices to the Syntax section. It doesn't really belong
 > there, but it makes no sense floating in Legality Rules with no related text.
 
-Sorry, I had not noticed the Legality Rule.  The update began by just fixing 
-the Name Resolution rules, but then I realized that I had to restrict the 
-syntax to make Name Resolution straightforward, and never went back and 
+Sorry, I had not noticed the Legality Rule.  The update began by just fixing
+the Name Resolution rules, but then I realized that I had to restrict the
+syntax to make Name Resolution straightforward, and never went back and
 looked at the whole AI.
- 
+
 >>    AARM Reason: If we allow multiple choices, we would have a new
 >>    overload resolution challenge, where you could have multiple
 >>    ranges requiring resolution across them.  We disallow single values
@@ -1861,123 +1876,123 @@
 >>    there is no applicable index constraint.  The user can use a
 >>    qualified expression if they really need to use the full flexibility
 >>    of array-aggregate notation.
-> 
-> We can do better than "weird". I used "useless". I wanted to use "only 
+>
+> We can do better than "weird". I used "useless". I wanted to use "only
 > useful for an obfuscated code contest", 'cause I was thinking about:
-> 
+>
 >   [for I in 1 => I]'Reduce ("+", A)
-> 
+>
 > which is a really complicated way to add 1 to A. Of course, we still allow:
-> 
+>
 >   [for I in 0..1 => I]'Reduce ("+", A)
 
 I presume you meant:
 
    [for I in 1..1 => I]'Reduce ...
 
-> 
-> which is an even more complicated way to add 1 to A. So I just settled 
+>
+> which is an even more complicated way to add 1 to A. So I just settled
 > on "useless". :-)
 
 Fine.
 
 >> ---
->> 
+>>
 >> Name Resolution
->> 
->> Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on 
+>>
+>> Change "R" and "I" to "Acc_Type" and "Val_Type" throughout (based on
 >> a suggestion by Randy).
-> 
+>
 > I added a short AARM note to this:
-> 
->   AARM Discussion: Acc_Type is short for accumulator type (the result 
+>
+>   AARM Discussion: Acc_Type is short for accumulator type (the result
 > of the
 >   reduction), and Val_Type is short for value type (the type of the input
 >   values to the reduction).
 
 Fine.
 
-> 
-> I could see making something like this NOTE, except that notes are all 
+>
+> I could see making something like this NOTE, except that notes are all
 > at the bottom when its far too late for these to do any good.
 
 Agreed.
 
-> 
+>
 >> ---
->> 
+>>
 >> Dynamic Semantics
->> 
+>>
 >> Replace the following:
->> 
+>>
 >> Dynamic Semantics
->> 
->> For a reduction_attribute_reference, the value_sequence is first 
+>>
+>> For a reduction_attribute_reference, the value_sequence is first
 >> evaluated.
->> For a value_sequence with or without the reserved word parallel, the 
->> evaluation of a value_sequence is as defined for an array aggregate 
+>> For a value_sequence with or without the reserved word parallel, the
+>> evaluation of a value_sequence is as defined for an array aggregate
 >> (see 4.3.3).
 >> The reduction_attribute_designator is then evaluated.
->> 
+>>
 >> with:
->> 
+>>
 >> Dynamic Semantics
->> 
->> For the evaluation of a value_sequence, the evaluation proceeds as 
+>>
+>> For the evaluation of a value_sequence, the evaluation proceeds as
 >> for a single-dimensional array aggregate (see
->> 4.3.3) with component type being Val_Type and with index type as 
->> defined above, with the sequence of values of the value_sequence 
->> corresponding to the components of the notional array so defined, in 
+>> 4.3.3) with component type being Val_Type and with index type as
+>> defined above, with the sequence of values of the value_sequence
+>> corresponding to the components of the notional array so defined, in
 >> increasing index order.
-> 
-> You didn't edit the following AARM notes. I tried to scrub the 
+>
+> You didn't edit the following AARM notes. I tried to scrub the
 > discussion of "array aggregate" from them while leaving the gist.
 
-Again, I was sort of trying to do a minimal change.  The notes that followed 
-didn't seem too bad as is, since we are talking about a "notional" array 
+Again, I was sort of trying to do a minimal change.  The notes that followed
+didn't seem too bad as is, since we are talking about a "notional" array
 aggregate.
- 
+
 > AARM Discussion:
-> The presence of the parallel keyword does not effect the evaluation of 
-> the value_sequence. Conceptually, a sequential sequence of values is 
+> The presence of the parallel keyword does not effect the evaluation of
+> the value_sequence. Conceptually, a sequential sequence of values is
 > produced, as though the parallel keyword were not present.
-> 
+>
 > AARM Implementation Note:
-> The intended implementation model is that a value_sequence generally 
-> avoids producing a temporary object, and instead issue calls to the 
-> Reducer as values are produced by the evaluation of the 
+> The intended implementation model is that a value_sequence generally
+> avoids producing a temporary object, and instead issue calls to the
+> Reducer as values are produced by the evaluation of the
 > value_sequence.
-> 
-> You might have intended to remove the first AARM note completely - I 
-> couldn't tell since you didn't mention them at all. (I don't think the 
-> first one says much interesting, and in some sense it is wrong, since 
-> the evaluation is likely to be different, at least at the generated 
-> code level, if the reduction is parallel. Esp. if we have a container 
-> iterator.) The second note definitely has value, since we want to say 
-> that even though this evaluated roughly like an aggregate, we're not 
+>
+> You might have intended to remove the first AARM note completely - I
+> couldn't tell since you didn't mention them at all. (I don't think the
+> first one says much interesting, and in some sense it is wrong, since
+> the evaluation is likely to be different, at least at the generated
+> code level, if the reduction is parallel. Esp. if we have a container
+> iterator.) The second note definitely has value, since we want to say
+> that even though this evaluated roughly like an aggregate, we're not
 > expecting an object to be created by the evaluation.
 
-I am fine with them, thought they are of course not normative, and that is 
+I am fine with them, thought they are of course not normative, and that is
 as it should be in my view.
- 
+
 >> ---
->> 
->> Replace the paragraphs defining the V'Reduce attribute with the 
+>>
+>> Replace the paragraphs defining the V'Reduce attribute with the
 >> following:
->> 
+>>
 >> The following attribute is defined for a value_sequence V:
->> 
+>>
 >> V'Reduce (/reducer_/name, /initial_value_/expression[,
 >> /combiner_/name])
 > ...
-> 
-> I assumed that you were leaving the AARM notes alone. They still seem 
-> relevant (although you might have simplified some of the wording had 
+>
+> I assumed that you were leaving the AARM notes alone. They still seem
+> relevant (although you might have simplified some of the wording had
 > you edited them).
 
 Yes, again I was *trying* to make a minimal change.
- 
-> It goes without saying that I had to delete a bunch of extra spaces 
+
+> It goes without saying that I had to delete a bunch of extra spaces
 > after periods. :-)
 
 I hope I get some credit for being consistent... ;-)
@@ -1987,104 +2002,149 @@
 From: Randy Brukardt
 Sent: Monday, January 21, 2019  7:57 PM
 
-... 
-> > We can do better than "weird". I used "useless". I wanted to use 
+...
+> > We can do better than "weird". I used "useless". I wanted to use
 > > "only useful for an obfuscated code contest", 'cause I was thinking about:
-> > 
+> >
 > >   [for I in 1 => I]'Reduce ("+", A)
-> > 
-> > which is a really complicated way to add 1 to A. Of course, we still 
+> >
+> > which is a really complicated way to add 1 to A. Of course, we still
 > > allow:
-> > 
+> >
 > >   [for I in 0..1 => I]'Reduce ("+", A)
-> 
+>
 > I presume you meant:
-> 
+>
 >    [for I in 1..1 => I]'Reduce ...
 
-That too. I did mean what I said, assuming that "+" is predefined or at least 
+That too. I did mean what I said, assuming that "+" is predefined or at least
 acts like that, so that adding zero does nothing. I was trying to get the most
-insane way of adding one, and more that it does, the better. That's the 
+insane way of adding one, and more that it does, the better. That's the
 "point" of such contests, after all.
 
 ...
 > >> Dynamic Semantics
-> >> 
-> >> For the evaluation of a value_sequence, the evaluation proceeds as 
+> >>
+> >> For the evaluation of a value_sequence, the evaluation proceeds as
 > >> for a single-dimensional array aggregate (see
-> >> 4.3.3) with component type being Val_Type and with index type as 
-> >> defined above, with the sequence of values of the value_sequence 
-> >> corresponding to the components of the notional array so defined, 
+> >> 4.3.3) with component type being Val_Type and with index type as
+> >> defined above, with the sequence of values of the value_sequence
+> >> corresponding to the components of the notional array so defined,
 > >> in increasing index order.
-> > 
-> > You didn't edit the following AARM notes. I tried to scrub the 
+> >
+> > You didn't edit the following AARM notes. I tried to scrub the
 > > discussion of "array aggregate" from them while leaving the gist.
-> 
-> Again, I was sort of trying to do a minimal change.  The notes that 
-> followed didn't seem too bad as is, since we are talking about a 
+>
+> Again, I was sort of trying to do a minimal change.  The notes that
+> followed didn't seem too bad as is, since we are talking about a
 > "notional" array aggregate.
 
-This weekend, I started worrying about that array aggregate in the case of a 
+This weekend, I started worrying about that array aggregate in the case of a
 parallel reduce.
 
-For a container iterator, an array aggregate always uses a forward 
-(sequential) iteration. (That would be more necessary, if such a thing is 
-possible, if we allow iteration filters.) And elements have to be evaluated in 
+For a container iterator, an array aggregate always uses a forward
+(sequential) iteration. (That would be more necessary, if such a thing is
+possible, if we allow iteration filters.) And elements have to be evaluated in
 iteration order. According to the above, adding "parallel" doesn't change this.
 
-Thus, it would be necessary to materialize the "notional" array aggregate in 
-order to apply any parallelism to the resulting "notional" array aggregate. 
+Thus, it would be necessary to materialize the "notional" array aggregate in
+order to apply any parallelism to the resulting "notional" array aggregate.
 Moreover, we're not using any of the parallel iteration mechanism here.
 
-Note that the above wording works fine if (1) It is a sequential reduce; (2) 
-The iterator is the kind without an iterator_specification; (3) The iterator 
-doesn't support the parallel_iterator_interface. (2) might require a bit more 
-explanation: a regular iterator allows the expressions to be evaluated in an 
-arbitrary order, so there is no problem doing that in parallel without 
-materializing the aggregate. [Note that adding a filter will destroy this 
-property, it would have to be evaluated sequentially as with the other 
-iterators; it would require the two iteration model at a minimum, and I'd 
+Note that the above wording works fine if (1) It is a sequential reduce; (2)
+The iterator is the kind without an iterator_specification; (3) The iterator
+doesn't support the parallel_iterator_interface. (2) might require a bit more
+explanation: a regular iterator allows the expressions to be evaluated in an
+arbitrary order, so there is no problem doing that in parallel without
+materializing the aggregate. [Note that adding a filter will destroy this
+property, it would have to be evaluated sequentially as with the other
+iterators; it would require the two iteration model at a minimum, and I'd
 expect that we'd share the wording.]
 
-What we want, I think, is to use the parallel iterator if it is available 
-and this is a parallel reduction. Also, note that the "length-determining" 
-pass is pointless for a reduction. So we probably do want to duplicate at 
-least some of the array aggregate wording here, because it can be simplified 
+What we want, I think, is to use the parallel iterator if it is available
+and this is a parallel reduction. Also, note that the "length-determining"
+pass is pointless for a reduction. So we probably do want to duplicate at
+least some of the array aggregate wording here, because it can be simplified
 and made to execute in parallel.
 
 Maybe something like:
 
-    For evaluation of a value_sequence that contains an 
-    iterator_specification, an iteration is performed for that 
-    iterator_specification (as described in 5.5.2), and for each value 
+    For evaluation of a value_sequence that contains an
+    iterator_specification, an iteration is performed for that
+    iterator_specification (as described in 5.5.2), and for each value
     produced, the associated expression is evaluated, its value is converted
-     to Val_Type, and used to define the next value produced by the 
-    value_sequence. If the value_sequence includes the reserved word parallel, 
-    a parallel iteration is performed; otherwise, a sequential iteration is 
+     to Val_Type, and used to define the next value produced by the
+    value_sequence. If the value_sequence includes the reserved word parallel,
+    a parallel iteration is performed; otherwise, a sequential iteration is
     performed.
 
-    For the evaluation of some other value_sequence, the evaluation proceeds 
-    as for a single-dimensional array aggregate (see 4.3.3) with component 
-    type being Val_Type and with index type as defined above, with the 
-    sequence of values of the value_sequence corresponding to the components 
+    For the evaluation of some other value_sequence, the evaluation proceeds
+    as for a single-dimensional array aggregate (see 4.3.3) with component
+    type being Val_Type and with index type as defined above, with the
+    sequence of values of the value_sequence corresponding to the components
     of the notional array so defined, in increasing index order.
 
-I think I'm missing some of the needed wording here (I lifted the first part 
+I think I'm missing some of the needed wording here (I lifted the first part
 from the wording for array aggregates, but I'm not sure if we need to say more
-about the correspondence of the values with the nominal index values), but I 
-wanted to bring up this problem so we can consider fixes (or whether we want 
+about the correspondence of the values with the nominal index values), but I
+wanted to bring up this problem so we can consider fixes (or whether we want
 to fix it).
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Monday, January 21, 2019  9:34 PM
+
+...
+> What we want, I think, is to use the parallel iterator if it is
+> available and this is a parallel reduction. Also, note that the
+> "length-determining" pass is pointless for a reduction. So we probably
+> do want to duplicate at least some of the array aggregate wording here,
+> because it can be simplified and made to execute in parallel.
+
+I guess we also still need to add the maximum-chunks specification to the
+parallel reduce.
+
+> I think I'm missing some of the needed wording here (I lifted the
+> first part from the wording for array aggregates, but I'm not sure if
+> we need to say more about the correspondence of the values with the
+> nominal index values), but I wanted to bring up this problem so we can
+> consider fixes (or whether we want to fix it).
+
+I'd be happy to take another shot at it if you would like.  What you have
+suggested seems pretty close already.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 21, 2019  10:09 PM
+
+Please do. I promised to get seven large AIs into the draft Standard this
+week, which seemed doable. But I didn't count on two snow days, nor the
+number of notes about errors in the wording. (Perhaps I should have
+predicted the latter, the former is rather hard to predict.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 27, 2019  10:45 PM
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Sunday, January 27, 2019  10:45 PM
 
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 27, 2019  10:45 PM
+
+
 The definition of Parallel_Reduce reads:
 
 X'Parallel_Reduce(Reducer, Initial_Value[, Combiner])
    X'Parallel_Reduce is a reduction expression that yields a result
-   equivalent to replacing the prefix of the attribute with the 
+   equivalent to replacing the prefix of the attribute with the
    value_sequence:
      [parallel for Item of X => Item]
 
@@ -2092,7 +2152,7 @@
     X'Parallel_Reduce("+", 0)
 would give us:
     [parallel for Item of X => Item]'Parallel_Reduce("+", 0)
-which is a bit of a problem, since there is no Parallel_Reduce attribute for a 
+which is a bit of a problem, since there is no Parallel_Reduce attribute for a
 value_sequence!
 
 We have to say something about the attribute identifier as well:
@@ -2105,10 +2165,10 @@
 
 ---
 
-None of these attributes ever say that they are in the form of 
-reduction_attribute_references. That seems kinda important, since the 
-resolution rules are based on that. I suppose that we can skip that 
-information for the object forms, since they are defined by equivalence, 
+None of these attributes ever say that they are in the form of
+reduction_attribute_references. That seems kinda important, since the
+resolution rules are based on that. I suppose that we can skip that
+information for the object forms, since they are defined by equivalence,
 but not for the value_sequence form.
 
 ---
@@ -2119,9 +2179,9 @@
 
 V'Reduce(/reducer_/name, /initial_value_/expression[, /combiner_/name])
 
-This attribute name is far too long to fit into the existing attribute annex, 
-it would extend all the way across the page or beyond. Moreover, we want 
-these parts to come from the definition for a reduction_attribute_designator 
+This attribute name is far too long to fit into the existing attribute annex,
+it would extend all the way across the page or beyond. Moreover, we want
+these parts to come from the definition for a reduction_attribute_designator
 and not from this description. Note that First is defined as
 
 First(N)
@@ -2141,22 +2201,22 @@
    begins by evaluating the value_sequence V and the parts of the
    reduction_attribute_designator (the /reducer_/name Reducer, the
    /initial_value_/expression Initial_Value, and the /combiner_/name Combiner,
-   if any), in any order. It then initializes the /accumulator/ of the 
+   if any), in any order. It then initializes the /accumulator/ of the
    reduction expression to the value of the /initial_value_/expression (the
-   /initial value/). 
+   /initial value/).
 
    ...
 
 ---
 
-The original wording for this AI had "reducer_subprogram" and 
-"combiner_subprogram" all over the place, but such syntax was not defined. We 
-don't want to use syntax terms that don't actually relate to the syntax. 
-Luckily, there isn't much use of those that can't be easily replace by 
-"subprogram denoted by the reducer_name" or just Reducer (in the attribute 
+The original wording for this AI had "reducer_subprogram" and
+"combiner_subprogram" all over the place, but such syntax was not defined. We
+don't want to use syntax terms that don't actually relate to the syntax.
+Luckily, there isn't much use of those that can't be easily replace by
+"subprogram denoted by the reducer_name" or just Reducer (in the attribute
 definition).
 
-Since this AI will be revoted at the next meeting (because of the extensive 
+Since this AI will be revoted at the next meeting (because of the extensive
 wording changes), I won't try to record all of this in detail.
 
 ---
@@ -2165,7 +2225,316 @@
 
 For blah, the following attributes are defined:
 
-Otherwise, the tools don't work (the attribute annex is created directly out 
+Otherwise, the tools don't work (the attribute annex is created directly out
 of the attribute text, I can't reorder anything).
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 29, 2019  3:58 PM
+
+All of your proposed edits make sense to me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 30, 2019  10:00 PM
+
+OK, here is yet another update to AI12-0262-1.  Since we are going to re-vote
+it, I went ahead and added the chunk_specification.  I also abandoned any use
+of the array aggregate -- it just didn't buy enough, and it interfered with
+evaluating the value_sequence in parallel for the case of:
+
+     [for I in 1..N => F(I)]'Reduce(...)
+
+[This was merged with version /08 to produce version /09 - Editor.]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 31, 2019  7:58 AM
+
+I found one typo: "reserved work parallel" should be "reserved word parallel"
+in the Legality Rules.  Also, the !discussion still mentions array aggregates,
+but that is probably OK since it is explaining the choice to use
+iterated_component_association rather than iterated_element_association with
+its more general loop_parameter_specification.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 31, 2019  3:09 PM
+
+I had found and fixed a number of typos (including that one) in my working
+version of that AI. I wasn't expecting a complete redo from you or I would
+have sent you that working version to start with. I guess I'll have to merge
+that. Grumble.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 31, 2019  4:16 PM
+
+Sorry.  When I started it became clear that some serious re-wording of the
+Dynamic Semantics was necessary.  I didn't change that much else.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February  1, 2019  9:10 PM
+
+..
+> > I had found and fixed a number of typos (including that one) in my 
+> > working version of that AI. I wasn't expecting a complete redo from 
+> > you or I would have sent you that working version to start with. I 
+> > guess I'll have to merge that. Grumble.
+> 
+> Sorry.  When I started it became clear that some serious 
+> re-wording of the Dynamic Semantics was necessary.  I didn't 
+> change that much else.
+
+I'll live. Just venting.
+
+---
+
+Anyway, I didn't see anything in your wording about either banning the "in"
+form of chunk_specification or giving it a meaning (and there doesn't seem to
+be any meaning for that). Did you forget to do that, or were you intending to
+just ignore it, figuring that no one would use it??
+
+---
+
+You also never described where the chunk_specification is elaborated. Your 
+wording just says:
+
+... If there is a chunk_specification, it determines the maximum number of chunks, 
+as defined in 5.5; otherwise the maximum number of chunks is implementation 
+defined.
+
+Clearly, it has to be elaborated before you do any of the iteration mentioned 
+in the previous bullets. I'd probably suggest that it be elaborated first in 
+the value_sequence. Maybe start the bullets with:
+
+For evaluation of a value_sequence{, the chunk_specification (if any) is 
+elaborated as described in 5.5, then}:
+
+(Note that 5.5 doesn't separately define the elaboration of a 
+chunk_specification, rather it is described only as part of a loop statement. 
+Perhaps we ought to slightly rewrite that so it can stand alone? OTOH, that's 
+pretty much true for all of the iteration text, so maybe fixing the one isn't 
+worth it. I doubt anyone is volunteering to rewrite the whole thing so it 
+truly can stand alone - 'twas hard enough to get it right as it is.)
+
+---
+
+One thing that we both missed is that the wording says the reduction arguments 
+are evaluated "in any order". But the magic words in Ada are "in an arbitrary 
+order"; that's indexed when it occurs as it triggers the anti-order-dependence 
+rules and various 11.6 rules. We probably mean that here and need to use those 
+words (at least something with "arbitrary order".
+
+---
+
+You didn't see any of the obvious/necessary simplifications to the wording 
+that I had, but at least that made it easier for me to merge. :-)
+
+---
+
+I didn't make any changes (other than the merge) to your wording yet, pending 
+finding out if there is a Legality Rule missing or something else. (The two 
+chunk_specification issues that start this message are open.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February  1, 2019  10:03 PM
+
+...
+> Anyway, I didn't see anything in your wording about either banning the "in"
+> form of chunk_specification or giving it a meaning (and there doesn't 
+> seem to be any meaning for that). Did you forget to do that, or were 
+> you intending to just ignore it, figuring that no one would use it??
+
+I believe there was a syntax rule saying that the chunk_specification must be 
+an /integer_/simple_expression.  It comes just before the Name_Resolution 
+rules.
+
+> ---
+> 
+> You also never described where the chunk_specification is elaborated. 
+> Your wording just says:
+> 
+> ... If there is a chunk_specification, it determines the maximum 
+> number of chunks, as defined in 5.5; otherwise the maximum number of 
+> chunks is implementation defined.
+> 
+> Clearly, it has to be elaborated before you do any of the iteration 
+> mentioned in the previous bullets. I'd probably suggest that it be 
+> elaborated first in the value_sequence. Maybe start the bullets with:
+
+I presumed we could rely on the fact that "determining the maximum number of 
+chunks" already implies doing the elaboration, etc.
+
+> For evaluation of a value_sequence{, the chunk_specification (if any) 
+> is elaborated as described in 5.5, then}:
+> 
+> (Note that 5.5 doesn't separately define the elaboration of a 
+> chunk_specification, rather it is described only as part of a loop 
+> statement. Perhaps we ought to slightly rewrite that so it can stand alone?
+> OTOH, that's pretty much true for all of the iteration text, so maybe 
+> fixing the one isn't worth it. I doubt anyone is volunteering to 
+> rewrite the whole thing so it truly can stand alone - 'twas hard 
+> enough to get it right as it
+> is.)
+
+I don't see a compelling need to pull it out, as long as we agree that we are 
+using the "same" dynamic semantics for chunk_specification as defined in 5.5.
+If you believe that is too much hand-waving, I'll am happy to adopt the 
+additional wording you suggested above.
+ 
+> ---
+> 
+> One thing that we both missed is that the wording says the reduction 
+> arguments are evaluated "in any order". But the magic words in Ada are 
+> "in an arbitrary order"; that's indexed when it occurs as it triggers 
+> the anti-order-dependence rules and various 11.6 rules. We probably 
+> mean that here and need to use those words (at least something with 
+> "arbitrary order".
+
+Agreed.
+ 
+> ---
+> 
+> You didn't see any of the obvious/necessary simplifications to the 
+> wording that I had, but at least that made it easier for me to merge. 
+> :-)
+...
+
+OK, glad to hear it was too much of a pain to merge.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  4, 2019  9:41 PM
+
+...
+> > Anyway, I didn't see anything in your wording about either banning 
+> > the
+"in"
+> > form of chunk_specification or giving it a meaning (and there 
+> > doesn't seem to be any meaning for that). Did you forget to do that, 
+> > or were you intending to just ignore it, figuring that no one would use it??
+> 
+> I believe there was a syntax rule saying that the chunk_specification 
+> must be an /integer_/simple_expression.
+> It comes just before the Name_Resolution rules.
+
+Missed that (twice). Not sure how I missed it in the file compare, but I 
+probably only looked at Legality Rules when I missed it. (Aside: that 
+happens a lot; I don't think of the Syntax heading as a place for Legality 
+Rules. I realize there are a bunch of them there, but I often miss those.
+Grump.)
+
+> > You also never described where the chunk_specification is elaborated. 
+> > Your wording just says:
+> > 
+> > ... If there is a chunk_specification, it determines the maximum 
+> > number of chunks, as defined in 5.5; otherwise the maximum number of 
+> > chunks is implementation defined.
+> > 
+> > Clearly, it has to be elaborated before you do any of the iteration 
+> > mentioned in the previous bullets. I'd probably suggest that it be 
+> > elaborated first in the value_sequence. Maybe start the bullets with:
+> 
+> I presumed we could rely on the fact that "determining the maximum 
+> number of chunks" already implies doing the elaboration, etc.
+> > 
+> > For evaluation of a value_sequence{, the chunk_specification (if 
+> > any) is elaborated as described in 5.5, then}:
+> > 
+> > (Note that 5.5 doesn't separately define the elaboration of a 
+> > chunk_specification, rather it is described only as part of a loop 
+> > statement. Perhaps we ought to slightly rewrite that so it can stand alone?
+> > OTOH, that's pretty much true for all of the iteration text, so 
+> > maybe fixing the one isn't worth it. I doubt anyone is volunteering 
+> > to rewrite the whole thing so it truly can stand alone - 'twas hard 
+> > enough to get it right as it
+> > is.)
+> 
+> I don't see a compelling need to pull it out, as long as we agree that 
+> we are using the "same" dynamic semantics for chunk_specification as 
+> defined in 5.5.  If you believe that is too much hand-waving, I'll am 
+> happy to adopt the additional wording you suggested above.
+
+The semantics in 5.5 start by saying that it applies to a loop_statement 
+"For the execution of a loop_statement...". The semantics of elaborating a 
+chunk_specification starts "If a chunk_specification is present in a 
+parallel loop...". We're not talking about any sort of statement here at all, 
+nor any sort of explicit loop, so using this wording is a stretch.
+
+Now, given the lack of any other wording, one can apply the Dewar rule to 
+come to the conclusion that you are supposed to copy this semantics even 
+though you aren't dealing with any sort of loop or statement, but that's 
+the sort of leap that we'd hope to avoid.
+
+There probably ought to be a paragraph in 5.5 simply dedicated to the 
+elaboration and meaning of a chunk_specification, without referring to any 
+particular parallel construct. 
+
+For instance, we could rewrite 5.5(8.1/5) as follows:
+
+If the reserved word parallel is present in the iteration_scheme of a 
+loop_statement (a parallel loop), the loop is a parallel construct which 
+directly contains the iteration.
+
+For an iteration that is directly part of a parallel construct, the iterations 
+are partitioned into one or more chunks, each with its own separate logical 
+thread of control (see clause 9). If a chunk_specification is present in such
+a construct, it is elaborated first, and the result of the elaboration 
+determines the maximum number of chunks used for the parallel construct. If 
+the chunk_specification is an integer_simple_expression, the elaboration 
+evaluates the expression, and the value of the expression determines the 
+maximum number of chunks. If a discrete_subtype_definition is present, the 
+elaboration elaborates the discrete_subtype_definition, which defines the 
+subtype of the chunk parameter, and the number of values in this subtype 
+determines the maximum number of chunks. After elaborating the 
+chunk_specification, a check is made that the determined maximum number of 
+chunks is greater than zero. If this check fails, Program_Error is raised. 
+If there is no chunk_specification, the number of chunks is implementation 
+defined.
+
+Now, we can reference the entire chunk thing by just saying that whatever 
+is a parallel construct that directly contains the iteration.
+
+That is, replace the parallel part of 4.5.10(29/5) by something like:
+
+If the reserved word parallel is present in the value_sequence, the enclosing 
+reduction_attribute_reference is a parallel construct directly containing a 
+parallel iteration that generates the sequence of values is generated by a 
+parallel iteration (as defined in 5.5, 5.5.1, and 5.5.2), as a set of 
+non-empty, non-overlapping contiguous chunks (subsequences) with one logical 
+thread of control (see clause 9) associated with each subsequence. The 
+maximum number of chunks is determined as defined in 5.5.
+
+In an ideal world, the entirety of 5.5 and 5.5.2 should be rewritten similarly 
+so that referencing how iteration works from aggregates and quantified 
+expressions and reductions aren't somehow leaping from loop statements to 
+some sort of expression. But I don't have the energy to do that...
+
+Aside: 5.5 defines parallel iteration for "normal" discrete iteration, so the 
+4.5.10(29/5) wording needs to reference that when talking about parallel 
+iteration, at a minimum.
+
+...
+> > You didn't see any of the obvious/necessary simplifications to the 
+> > wording that I had, but at least that made it easier for me
+> to merge. 
+> > :-)
+...
+> 
+> OK, glad to hear it was too much of a pain to merge.
+
+Freudian slip?? :-) :-)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent