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

Differences between 1.14 and version 1.15
Log of other versions for file ai12s/ai12-0242-1.txt

--- ai12s/ai12-0242-1.txt	2019/01/11 05:38:16	1.14
+++ ai12s/ai12-0242-1.txt	2019/01/13 05:14:53	1.15
@@ -1,4 +1,4 @@
-!standard 4.5.9 (0)                                19-01-10    AI12-0242-1/07
+!standard 4.5.9 (0)                                19-01-12    AI12-0242-1/08
 !class Amendment 14-06-20
 !status work item 14-06-20
 !status received 14-06-17
@@ -62,39 +62,22 @@
 
 !wording
 
-Modify 4.1.4(6)
+Modify 4.1.4(6):
 
-In an 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 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
-the prefix consists of a name that denotes a function, it is interpreted
-as a parameterless function_call.
-
-Modifies 4.1.4(14/2)
-
-In general, the name in a prefix of an attribute_reference{,}[(or a]
-range_attribute_reference{, or a reduction_attribute_reference}) has to be
-resolved without using any context. However, in the case of the Access attribute,
-the expected type for the attribute_reference has to be a single access type,
-and the resolution of the name can use the fact that the type of the object
-or the profile of the callable entity denoted by the prefix has to match the
-designated type or be type conformant with the designated profile of the
-access type.
-
-Modifies 4.1.4(14.a/2)
-
-Proof: In the general case, there is no "expected type" for the prefix of
-an attribute_reference{ (or reduction_attribute_reference)}. In the special
-case of 'Access, there is an "expected type" or "expected profile" for the
-prefix.
+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. 
 
-
 [Modifications to new subclause 4.5.9 added by AI12-0262-1]
 
 Modify Syntax of 4.5.9:
@@ -102,9 +85,9 @@
 reduction_attribute_reference ::= value_generator'reduction_attribute_designator
                                 {| prefix'reduction_attribute_designator}
 
-Modify AARM Note in Legality Rules of 4.5.9:
+Modify AARM Reason in Legality Rules of 4.5.9:
 
-AARM Note
+AARM Reason:
 For a reduction_attribute_reference with a value_sequence that does not
 have the {reserved word} parallel [keyword]{or has a prefix and the
 identifier of the reduction_attribute_designator is Reduce}, the
@@ -112,31 +95,22 @@
 logical thread of control is presumed so there is no need to provide a
 way to combine multiple results.
 
-Add Legality rule to subclause 4.5.9:
+Add a Legality Rule to subclause 4.5.9:
 
 If the identifier of a reduction_attribute_designator is Parallel_Reduce
 then the combiner_name of the reduction_specification shall be specified if
 the subtypes of all the parameters of the /reduce_/subprogram denoted by
 the reduction_specification do not statically match.
 
-Static Semantics
+Add the following to the Static Semantics of subclause 4.5.9:
 
 For a reduction_attribute_reference where the identifier of the
 reduction_attribute_designator is Parallel_Reduce, if the combiner_name
 is not specified, then the subprogram denoted by the reducer_subprogram also
 implicitly denotes the combiner_subprogram.
 
-Modify AARM note in Static Semantics of 4.5.9:
-AARM Note:
-For a reduction_attribute_reference that has a value_sequence without the
-parallel keyword {or a prefix where the identifer is Reduce}, 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.
 
-Dynamic Semantics
+Add the following to the Dynamic Semantics of subclause 4.5.9:
 
 The following attributes are defined for a prefix O that is of an
 array type (after any implicit dereference), or denotes an /iterable container
@@ -145,17 +119,29 @@
 O'Reduce(Reducer, Initial_Value[, Combiner])
 
    O'Reduce is a reduction expression that yields a result equivalent to
-   replacing the prefix of the attribute with the value_generator;
+   replacing the prefix of the attribute with the value_generator:
    [for Item of O => Item]
 
 
 O'Parallel_Reduce(Reducer, Initial_Value[, Combiner])
 
    O'Parallel_Reduce is a reduction expression that yields a result
-   equivalent to replacing the prefix of the attribute with the value_generator;
+   equivalent to prefix of the attribute with the value_generator:
    [parallel for Item of O => Item]
+
+Modify the second AARM Implementation Note in Dynamic Semantics of 4.5.9:
+AARM Implementation Note:
+For a reduction_attribute_reference that has a value_sequence without the 
+parallel keyword {or a prefix where the identifier of the 
+reduction_attribute_designator is Reduce}, 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.
 
-Examples
+Add the following to the Examples of subclause 4.5.9:
 
   --  Calculate the sum of elements of an array of integers
 

Questions? Ask the ACAA Technical Agent