CVS difference for ai22s/ai22-0011-1.txt
--- ai22s/ai22-0011-1.txt 2021/11/20 07:49:18 1.4
+++ ai22s/ai22-0011-1.txt 2022/01/08 05:42:34 1.5
@@ -1,9 +1,20 @@
-!standard 4.5.10(18/5) 21-11-19 AI22-0011-1/03
+!standard 4.5.10(9/5) 22-01-07 AI22-0011-1/04
+!standard 4.5.10(10/5)
+!standard 4.5.10(12/5)
+!standard 4.5.10(13/5)
+!standard 4.5.10(15/5)
+!standard 4.5.10(16/5)
+!standard 4.5.10(17/5)
+!standard 4.5.10(18/5)
+!standard 4.5.10(19/5)
+!standard 4.5.10(20/5)
!standard 4.5.10(24/5)
!standard 4.5.10(25/5)
!standard 4.5.10(27/5)
!standard 4.5.10(29/5)
+!standard 4.5.10(34/5)
!class binding interpretation 21-11-11
+!status ARG Approved 11-0-0 21-11-18
!status work item 21-11-11
!status received 21-04-28
!priority Low
@@ -31,13 +42,18 @@
a conversion to the accumulator subtype, which may fail). RM 4.5.10(29/5)
incorrectly states otherwise.
-4) The result of a reduction expression has the nominal subtype of Accum_Type
- (which is a subtype, despite its name). However, the initial value may
- have some other subtype (the only requirement is that it have the type of
- Accum_Type). Similarly, the expression of the iterated_element_association
- may not belong to Accum_Type. We need wording to convert these to the
- appropriate subtype. (Note that the parameter and/or result of the reducer
- subprogram does have the correct subtype and does not need a conversion.)
+4) Accum_Type is a subtype, despite its name. The same applies to Value_Type.
+ We work around this by saying Accum_Type subtype all over the place.
+ It would be better to call these Accum_Subtype and Value_Subtype in the
+ first place.
+
+5) The result of a reduction expression has the nominal subtype of Accum_Type.
+ However, the initial value may have some other subtype (the only
+ requirement is that it have the type of Accum_Type). Similarly, the
+ expression of the iterated_element_association may not belong to
+ Accum_Type. We need wording to convert these to the appropriate subtype.
+ (Note that the parameter and/or result of the reducer subprogram does have
+ the correct subtype and does not need a conversion.)
Should these be fixed? (Yes.)
@@ -47,21 +63,97 @@
!wording
+Modify 4.5.10(9/5):
+
+ In the remainder of this subclause, we will refer to nonlimited subtypes
+ [*Value_Type*]{*Value_Subtype*} and [*Accum_Type*]{*Accum_Subtype*} of a
+ reduction_attribute_reference. These subtypes and interpretations of the
+ names and expressions of a reduction_attribute_reference are determined
+ by the following rules:
+
+Modify 4.5.10(10/5):
+
+ * [*Accum_Type*]{*Accum_Subtype*} is a subtype of the expected type of
+ the reduction_attribute_reference.
+
+Replace 4.5.10(12/5) with:
+
+ function Reducer(Accumulator : Accum_Subtype;
+ Value : Value_Subtype) return Accum_Subtype;
+
+Replace 4.5.10(13/5) with:
+
+ procedure Reducer(Accumulator : in out Accum_Subtype;
+ Value : in Value_Subtype);
+
+Modify 4.5.10(15/5):
+
+ * The expected type of an initial_value_expression of a
+ reduction_specification is [that of subtype *Accum_Type*]{the type of
+ *Accum_Subtype*}.
+
+Modify 4.5.10(16/5):
+
+ * The expected type of the expression of the
+ iterated_element_association of a value_sequence is [that of subtype
+ *Value_Type*]{the type of *Value_Subtype*}.
+
+Modify 4.5.10(17/5):
+
+ If the reduction_attribute_reference has a value_sequence with the reserved
+ word parallel, [the subtypes *Accum_Type* and *Value_Type*]{*Accum_Subtype*
+ and *Value_Subtype*} shall statically match.
+
+Modify 4.5.10(18/5):
+
+ If the identifier of a reduction_attribute_designator is Parallel_Reduce,
+ [the subtypes *Accum_Type* and *Value_Type*]{*Accum_Subtype* and
+ *Value_Subtype*} shall statically match.
+
+Modify AARM 4.5.10(18.a/5):
+
+ For a reduction_attribute_reference with a value_sequence that does not
+ have the reserved word parallel or has a prefix and the identifier of the
+ reduction_attribute_designator is Reduce, [the subtypes *Accum_Type* and
+ *Value_Type*]{*Accum_Subtype* and *Value_Subtype*} can be different because
+ only one logical thread of control is presumed so there is no need to
+ combine multiple results.
+
Add after 4.5.10(18/5) [at the end of the Legality Rules section].
+
+ The types of both *Accum_Subtype* and *Value_Subtype* shall not be an anonymous
+ access types.
- The types of both the *Accum_Type* subtype and the *Value_Type* subtype
- shall not be an anonymous access types.
+Replace 4.5.10(19/5) with:
+ A reduction_attribute_reference denotes a value, with its nominal subtype
+ being *Accum_Subtype* Redundant[(the subtype of the first parameter of the
+ subprogram denoted by the reducer_name)].
+
+[Editor's note: We didn't need to change this one, but it is odd and confusing
+to have a name for something and not use it in the rules. I left the old part
+as a parenthesized remark as it can be clarifying.]
+
+Modify 4.5.10(20/5):
+
+ For the evaluation of a value_sequence, the iterated_element_association,
+ the chunk_specification, and the aspect_specification, if any, are
+ elaborated in an arbitrary order. Next an iteration is performed, and for
+ each value conditionally produced by the iteration (see 5.5 and 5.5.2), the
+ associated expression is evaluated with the loop parameter having this
+ value, which produces a result that is converted to
+ [*Value_Type*]{*Accum_Subtype*} and is used to define the next value in the
+ sequence.
+
Modify 4.5.10(24/5):
The evaluation of a use of this attribute begins by evaluating the parts of
the reduction_attribute_designator (the reducer_name Reducer and the
initial_value_expression Initial_Value), in an arbitrary order. It then
{converts the the value of the initial_value_expression (the initial value)
- to the subtype Accum_Type and then }initializes the accumulator {with the
- result}[of the reduction expression to the value of the
- initial_value_expression (the initial value)]. The value_sequence V is then
- evaluated.
+ to *Accum_Subtype* and then }initializes the accumulator {with the result}[of
+ the reduction expression to the value of the initial_value_expression (the
+ initial value)]. The value_sequence V is then evaluated.
Add an AARM note after 4.5.10(24/5):
@@ -73,7 +165,7 @@
Modify 4.5.10(25/5):
If the value_sequence does not have the reserved word parallel, each value
- of the value_sequence is {converted to subtype Value_Type and then} passed,
+ of the value_sequence is {converted to *Value_Subtype* and then} 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
@@ -83,18 +175,28 @@
Each logical thread of control creates a local accumulator for processing
its subsequence. The accumulator for a subsequence is initialized to the
- {result of converting the} first value of the subsequence {to subtype
- Accum_Type}, and calls on Reducer start with the second value of the
+ {result of converting the} first value of the subsequence {to
+ *Accum_Subtype*}, and calls on Reducer start with the second value of the
subsequence (if any). The result for the subsequence is the final value
of its local accumulator.
-Replace RM 4.5.10(29/5)
- If the evaluation of the value_sequence yields an empty sequence of values,
- the reduction expression yields the initial value.
-with
+Modify 4.5.10(29/5):
+
If the evaluation of the value_sequence yields an empty sequence of values,
- the reduction expression yields the initial value of the accumulator.
+ the reduction expression yields the initial value{ of the accumulator}.
+Modify 4.5.10(34/5):
+
+ For a parallel reduction expression, it is a bounded error if the reducer
+ subprogram is not associative. That is, for any arbitrary values of
+ {*Value_Subtype*}[subtype Value_Type] A, B, C and a reducer function R, the
+ result of R (A, R (B, C)) should produce a result equal to
+ R (R (A, B), C)); it is a bounded error if R does not. The possible
+ consequences are Program_Error, or a result that does not match the
+ equivalent sequential reduction expression due to the order of calls on the
+ reducer subprogram being unspecified in the overall reduction. Analogous
+ rules apply in the case of a reduction procedure.
+
!discussion
Adding an AARM note for #1 is harmless at worst. It seems worthwhile
@@ -114,17 +216,21 @@
reducer function (as opposed to a reducer procedure).
It seems better to state this explicitly.
+The change for #4 clarifies most of the wording. Talking about the
+"Accum_Type subtype" is annoying, while the "type of Accum_Subtype" is a
+usual thing to talk about. So we make this change.
+
The change for #3 seems like a clear improvement; otherwise a
reduction expression might yield a result that is not within its
nominal subtype.
-But for that to be the case (#4), we need to convert the initial value and
-any expressions to the Accum_Type, so that any constraints or predicates
+But for that to be the case (#5), we need to convert the initial value and
+any expressions to the Accum_Subtype, so that any constraints or predicates
are respected. We chose to keep the accumulator(s) always having the
appropriate subtype. This is similar to what would happen if we had a
declaration for the accumulator:
- Accumulator : Accum_Type;
+ Accumulator : Accum_Subtype;
And in any case we have to check the value before passing it to a reducer,
so there is no real benefit in waiting.
Questions? Ask the ACAA Technical Agent