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

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

--- ai12s/ai12-0262-1.txt	2019/01/11 05:59:53	1.6
+++ ai12s/ai12-0262-1.txt	2019/01/13 05:14:33	1.7
@@ -1,4 +1,4 @@
-!standard 4.1.4(1)                                    19-01-10  AI12-0262-1/04
+!standard 4.1.4(1)                                    19-01-12  AI12-0262-1/05
 !standard 4.1.4(11)
 !standard 4.5.9(0)
 !class Amendment 18-03-01
@@ -162,28 +162,33 @@
 
 !wording
 
-Modify 4.1.4(1):
+Replace 4.1.4(2) with:
 
-An attribute is a characteristic of an entity that can be queried via an
-attribute_reference [or]{,} a range_attribute_reference{, or a
-reduction_attribute_reference (see 4.5.9)}.
+    attribute_reference ::= prefix'attribute_designator
+       | reduction_attribute_reference
 
+Modify 4.1.4(6):
 
-Modify AARM 4.1.4(9.b/3):
-Discussion: The nominal subtype is primarily a concern when an
-attribute_reference, {reduction_attribute_reference,} or a call on an
-attribute_reference, is used as the expression of a case statement, due to the
-full coverage requirement based on the nominal subtype. For nondiscrete cases,
-we define the nominal subtype mainly for completeness. Implementations may
-specify otherwise for implementation-defined attribute functions.
+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 
+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. 
+
+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 
+in 4.5.9.]
 
 
-Modify 4.1.4(11):
-
-The evaluation of an attribute_reference {,}[(or] range_attribute_reference[)]
-{, or reduction_attribute_reference} consists of the evaluation of the prefix
-{or value_sequence (see 4.5.9)}.
-
 New Section 4.5.9
 
 4.5.9 Reduction Expressions
@@ -210,7 +215,8 @@
 The expected type for a reduction_attribute_reference shall be a single
 nonlimited type.
 
-Given nonlimited subtypes I and R, where R is a subtype of the expected type:
+Given nonlimited subtypes I and R, where R is a subtype of the expected type
+of the reduction_attribute_reference:
 
 A /reducer_/subprogram is either subtype conformant with the following
 specification:
@@ -235,8 +241,8 @@
 subtype I.
 
 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).
+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 index
@@ -245,34 +251,27 @@
 
 Legality Rules
 
-[For a reduction_attribute_reference for a value_sequence with the parallel
-keyword, the Nonblocking aspect of the /reducer_/subprogram shall be statically
-True, and the Global aspect of the /reducer_/subprogram shall be statically
-null.]
-
- [Author's note: Randy says this rule is unnecessary, as it is covered by
-  parallel constructs in AI12-0267-01, is it worth keeping here?]
-
 The combiner_name of a reduction_specification shall be specified
 if the subtypes of the parameters of the /reducer_/subprogram denoted by the
 reduction_specification do not statically match each other and the
 reduction_attribute reference has a value_sequence with the reserved work
 parallel.
-
-The discrete_choice_list of a value_sequence shall have a single discrete_choice
-and the discrete_choice shall not be the reservered word others.
-
-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.
-
-AARM Note
 
+AARM Reason:
 For a reduction_attribute_reference with a value_sequence that does not
 have the parallel keyword, the combiner_name of the reduction_specification
 is optional because only one logical thread of control is presumed so there
 is no need to provide a way to combine multiple results.
+End AARM Reason.
+
+The discrete_choice_list of a value_sequence shall have a single discrete_choice
+and the discrete_choice shall not be the reservered word others.
 
+AARM Ramification: The discrete_choice_list of a value_sequence may 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. If the
+choice is a subtype_indication, the denoted subtype may have a static or
+dynamic predicate.
 
 Static Semantics
 
@@ -289,39 +288,24 @@
 subprogram denoted by the reducer_subprogram also implicitly denotes the
 combiner_subprogram.
 
-AARM Note:
-For a reduction_attribute_reference that has a value_sequence without the
-parallel keyword, if the combiner_name is not specified, then sequential
-execution is presumed if the subtypes of the parameters of the
-reducer_subprogram denoted by the reduction_specification do not statically
-match, since there is no subprogram identified in the construct that could be
-used for combining the results in parallel.
-
-AARM Ramification: If the subtypes of the parameters of reducer_subprogram
-do statically match, then sequential execution is presumed but the determination
-of whether to apply parallel execution is made by the compiler, dependent on
-the usual guarantees for delivering results that are equivalent to that which
-would be produced by sequential execution.
-
-
 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 (See 4.3.3).
+of a value_sequence is as defined for an array aggregate (see 4.3.3).
 The reduction_attribute_designator is then evaluated.
 
-AARM Note:
+AARM Discussion:
 The presence of the parallel keyword does not effect the evaluation of
 the value_sequence. Conceptually, an array aggregate is produced, as though
 the parallel keyword were not present.
 
-AARM Suggested Implementation
+AARM Implementation Note:
 The intended implementation model is that a value_sequence generally avoids
 producing a temporary array aggregate object, and instead issue calls to
 the Reducer as values are produced by the evaluation of the value_sequence.
 
-The following attribute is defined for a value_sequence V
+The following attribute is defined for a value_sequence V:
 
 V'Reduce(Reducer, Initial_Value[, Combiner])
 
@@ -336,7 +320,7 @@
    present in a value_sequence (a parallel reduction), then the reduction
    expression is a parallel construct and the iterations are partitioned into
    one or more chunks, each with its own separate logical thread of control (see
-   clause 9).  Each logical thread of control generates a local copy of the
+   clause 9). Each logical thread of control generates a local copy of the
    result of its iteration, which is initialized to the value of the expression
    produced by the first assigned iteration. As each logical thread of control
    completes its assigned iterations, the Combiner is called using the value of
@@ -345,23 +329,24 @@
    call. Once all logical threads of control have completed, yields the result
    of the last call to Combiner. The calls to Combiner are executed in
    increasing iteration order. The Combiner may be omitted if the Reducer is
-   also a combiner_subprogram. In that case, the Reducer is implicitly used also
-   as the Combiner argument.
-
-[**allow a tree evaluation??** - Tucker's comment, which the author does not understand]
+   also a combiner_subprogram. In that case, the Reducer is implicitly used
+   also as the Combiner argument.
 
    V'Reduce yields the value of the Initial_Value expression if the
    value_sequence of the reduction_attribute reference produces an empty
    sequence.
 
-NOTES
-
-The Initial_Value of a reduction expression is only evaluated once.
-
-The /reducer_/subprogram and the /combiner_/subprogram /potentially conflict/
-with other actions.
+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 
+reduction in parallel, presuming doing so would not change the results.
+However, if the combiner_name is not specified, then sequential
+execution is necessary if the subtypes of the parameters of the
+reducer_subprogram denoted by the reduction_specification do not statically
+match, since there is no subprogram identified in the construct that could be
+used for combining the results in parallel.
 
-AARM Note:
+AARM Discussion:
 
 We say the calls to Combiner are sequentially ordered in increasing order
 because certain reductions, such as vector concatentation,
@@ -369,16 +354,17 @@
 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.
+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.
 
-For the parallel version of 'Reduce, calls to Combiner are executed in
-increasing iteration order to provide determinism and results that are
-consistent with sequential execution. This can be important for certain
-reduction operations that are non-commutative, such as concatentation.
-This also implies 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.
+NOTES
+
+The Initial_Value of a reduction expression is only evaluated once.
+
+The /reducer_/subprogram and the /combiner_/subprogram /potentially conflict/
+with other actions.
 
 Examples
 
@@ -420,9 +406,9 @@
 
      My_String : String(1..10);
 
-        [for I in My_String'Range => My_String(I)]'Reduction (Standard'"&", "")
+        [for I in My_String'Range => My_String(I)]'Reduction (Standard."&", "")
                -- This is a terrible way to copy a string. :-)
-        String'[for I in My_String'Range => My_String(I)]'Reduction (Standard'"&", "")
+        String'[for I in My_String'Range => My_String(I)]'Reduction (Standard."&", "")
 
 The first reduction overall requires a single expected type; it can't be used in a type
 conversion, for instance. The type provided allows the rest of the reduction to resolve.
@@ -893,5 +879,174 @@
 even the introduction, not Legality Rules).
 
 I didn't make this change (maybe I should have).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 11, 2019  6:07 PM
+
+At the start of the new section, you have grammar:
+
+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 
+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 
+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 
+"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 
+"attribute_reference".
+
+Thus, I would suggest changing the syntax in 4.1.4 to:
+
+    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"] 
+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 
+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 
+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 
+reduction_attribute_reference would have a prefix.]
+
+----------
+
+In the Name Resolution Rules:
+
+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 
+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 
+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 
+suggest adding that to the start of the Static Semantics section:
+
+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 
+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 
+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 
+subtype_indication or range that defines a nonstatic or null range.
+
+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, 
+but it does complicate the implementation.)
+
+That is:
+
+        subtype Odd is Natural
+           with Static_Predicate => 1 | 3 | 5 | 7 | 9;
+
+        [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 
+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 
+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 
+reduction in parallel, presuming that would not change the results.
+However,} if the combiner ... 
+
+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.
+
+---------
+
+AARM Suggested Implementation
+
+No such thing. That's "AARM Implementation Note".
+
+-----
+
+Typo: Colon needed here:
+
+The following attribute is defined for a value_sequence V{:}
+
+-----
+
+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 
+organization made sense.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent