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

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

--- ai12s/ai12-0262-1.txt	2019/02/07 06:31:30	1.12
+++ ai12s/ai12-0262-1.txt	2019/02/12 04:17:23	1.13
@@ -1,9 +1,10 @@
-!standard 4.1.4(1)                                    19-02-01  AI12-0262-1/09
+!standard 4.1.4(1)                                    19-02-11  AI12-0262-1/10
 !standard 4.1.4(6)
 !standard 4.1.4(11)
 !standard 4.5.10(0)
 !class Amendment 18-03-01
 !status Amendment 1-2012 19-01-15
+!status ARG Approved 10-0-1  19-02-11
 !status work item 19-01-17
 !status ARG Approved 9-0-2  19-01-14
 !status work item 18-03-01
@@ -33,27 +34,27 @@
 declaring a type and without forcing the materialization of an object.
 
 To further illustrate the need, one of the most important additions to Ada 2012
-is contract specifications for subprograms. However to write pre and post
-conditions that attempt to summarize inputs or outputs, one has
+is contract specifications for subprograms. However to write pre- and 
+postconditions that attempt to summarize inputs or outputs, one has
 to write a subprogram to express the summary result, which can add clutter to
 an API for an abstraction and injects a level of indirection. If a client
-then wants to understand the requirements of the pre condition or the effects
-of the post condition, one has to find and examine the body of the subprogram
+then wants to understand the requirements of the precondition or the effects
+of the postcondition, one has to find and examine the body of the subprogram
 named in the contract specification.
 
 It would be useful if such summarizations could be expressed in a simpler, more
-concise and localized manner, such as an expression, without always having to
+concise, and localized manner, such as an expression, without always having to
 write another subprogram.
 
 Ada 83 was already a pretty good language for "hybrid" functional/imperative
 programming, because you can have a sequence of declarations that progressively
-compute a desired result.  Often it was only because you needed to enter a loop
-that you had to do any significant amount of computing after the "begin".  In
+compute a desired result. Often it was only because you needed to enter a loop
+that you had to do any significant amount of computing after the "begin". In
 today's Ada, with conditional expressions, quantified expressions, the recently
 approved iterated component association, and our newly proposed container
 aggregates, the need for explicit ifs and loops after the "begin" is continuing
-to decrease. There appears to be a shift in the a balance between functional
-and imperative features, more towards the functional side.  There is a
+to decrease. There appears to be a shift in the balance between functional
+and imperative features, more towards the functional side. There is a
 resurgence of interest in functional programming these days, but going all the
 way to "pure functional" programming, with "monads" instead of assignment
 statements, and recursion only with no iteration, would be too going too far
@@ -75,7 +76,7 @@
 
 Such a reduction capability is the last remaining major component needed to
 complete the "iterated" operations. There are many applications of reduction
-capabilities, that apply to both sequential and parallelism use cases.  It will often be
+capabilities, that apply to both sequential and parallelism use cases. It will often be
 the right way to define, in a postcondition, the final value of one
 output of the subprogram, even though the subprogram might have multiple outputs
 and might do many other things.
@@ -88,7 +89,7 @@
 platforms typically provide support for multicore computing, yet it can be
 considerably difficult to write algorithms that take advantage of these
 multicore platforms. Such algorithms tend to be very error prone, and are
-difficult to debug. Many of the divide and conquer algorithms involve reduction,
+difficult to debug. Many of the divide-and-conquer algorithms involve reduction,
 commonly known as Map-Reduce, in the parallelism world.
 
 The challenge with such algorithms when looping constructs are employed, is that
@@ -99,7 +100,7 @@
 Parallel reduction is in many ways a separate issue, when compared to sequential
 reduction, and where (and whether) it is best inserted depends heavily on the
 amount of computing done within a single iteration, the independence of those
-computations, and the number of iterations.  The advantage of the notations like
+computations, and the number of iterations. The advantage of the notations like
 quantified expressions, and container aggregates, is that they are self-contained,
 and can often be analyzed holistically by the compiler to determine whether and
 where to insert parallelism.
@@ -133,7 +134,7 @@
 
 The proposal defines a new type of attribute reference called a
 reduction expression that allows a special form of iterated_component_association
-called a value_sequence to be specified as the left hand side of the "'", and where
+called a value_sequence to be specified as the left-hand side of the "'", and where
 the attribute designator, Reduce, defines a reduction specification that indicates
 how the reduction is to be applied. The basic idea is that during the evaluation
 of the value_sequence, as each value is produced, it is reduced into
@@ -242,45 +243,45 @@
 nonlimited type.
 
 In the remainder of this subclause,
-we will refer to nonlimited subtypes Val_Type and Acc_Type of a
+we will refer to nonlimited subtypes Value_Type and Accum_Type 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:
 
-   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).
+   AARM Discussion: Accum_Type represents the result of the reduction (the 
+   accumulator type), and Value_Type represents the type of the input
+   values to the reduction.
 
-*  Acc_Type is a subtype of the expected type of the
+*  Accum_Type is a subtype of the expected type of the
    reduction_attribute_reference.
 
 *  A /reducer subprogram/ is either subtype conformant with the following
    specification:
 
-      function Reducer(Accumulator : Acc_Type; Value : Val_Type) return Acc_Type;
+      function Reducer(Accumulator : Accum_Type; Value : Value_Type) return Accum_Type;
 
    or is subtype conformant with the following specification:
 
-      procedure Reducer(Accumulator : in out Acc_Type; Value : in Val_Type);
+      procedure Reducer(Accumulator : in out Accum_Type; Value : in Value_Type);
 
 *  A /combiner subprogram/ is a reducer subprogram where both parameters are
-   of subtype Acc_Type.
+   of subtype Accum_Type.
 
 *  The /reducer_/name of a reduction_specification denotes a reducer subprogram.
 
 *  The /combiner_/name of a reduction_specification denotes a combiner subprogram.
 
 *  The expected type of an /initial_value_/expression of a reduction_specification
-   is that of subtype Acc_Type.
+   is that of subtype Accum_Type.
 
 *  The expected type of the expression of a value_sequence is that of
-   subtype Val_Type.
+   subtype Value_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
+   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
@@ -328,14 +329,14 @@
     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
+    this value, to produce a result that is converted to Value_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
+    this value, to produce a result that is converted to Value_Type, and
     used to define the next value in the sequence.
 
 If the value_sequence does not have the reserved word parallel, it is
@@ -345,7 +346,7 @@
 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,
+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.
 
@@ -357,12 +358,12 @@
    reduction_attribute_reference.
 
    The evaluation of a use of this attribute
-   begins by evaluating the value_sequence V and the parts of the
+   begins by evaluating 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 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/). The value_sequence V is then evaluated.
 
    If the value_sequence does not have the reserved word parallel, each
    value of the value_sequence is passed, in order, as the second
@@ -436,26 +437,31 @@
   specified, then it is a bounded error if the initial value is not the
   (left) identity of the combiner subprogram. That is, the result of
   calling the combiner subprogram with the Accumulator being the initial
-  value and the Value being any arbitrary value of subtype Acc_Type should
+  value and the Value being any arbitrary value of subtype Accum_Type should
   produce a result equal to the Value parameter. The possible consequences
   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,
+    reductions when the Accum_Type and the Value_Type are not the same,
     unless we can initialize the local accumulator with an initial-value
     that is presumed to be the identity. If the initial value is not
     the identity, and there is more than one chunk, it will be included
     more than once in the overall reduction. We associate this bounded
     error with there being a combiner subprogram specified, since that
-    is necessary only when Acc_Type and Val_Type are different, and
+    is necessary only when Accum_Type and Value_Type are different, and
     because the dynamic semantics above specify the use of the initial
     value multiple times whenever a combiner is specified. We chose to
     base the dynamic semantics rules on the presence of a separate
-    combiner, rather than on the matching between Acc_Type and Val_Type,
+    combiner, rather than on the matching between Accum_Type and Value_Type,
     since the presence of the combiner is more visible in the source.
 
+    AARM To Be Honest: In this rule, "equal" means semantically equal.
+    We don't care if the bit patterns differ but the results mean the same
+    thing. In particular, if the primitive equal is user-defined, that 
+    equality would be the one used to determine if this rule is violated.
+
 Examples
 
   --  An expression function that returns its result as a Reduction Expression
@@ -2542,6 +2548,110 @@
 > OK, glad to hear it was too much of a pain to merge.
 
 Freudian slip?? :-) :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 11, 2019  2:33 PM
+
+[Part of another thread:]
+
+Randy or anyone else, do you have notes on any other term(s) we wanted to give 
+a (better) name to?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 11, 2019  2:50 PM
+
+The term for whatever happens to a value_sequence before the actual reduction 
+happens. It currently says "evaluate", but that implies the values are 
+determined, when we're only talking about determining the iterator to execute. 
+The best suggestion there was "prepared".
+
+Didn't see any others in my notes, but I didn't look ultra-carefully.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 11, 2019  3:00 PM
+
+Ah yes, prepared, initiated, hazed, ...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 11, 2019  3:04 PM
+
+Slightly more seriously, perhaps a value_sequence is "deployed."
+
+   For the deployment of a value_sequence:
+     ...
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Monday, February 11, 2019  3:26 PM
+
+In my preference list, "prepared" is first, and "deployed" is second.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 11, 2019  8:15 PM
+
+What he said. I'm going to use "prepared" unless some obviously better idea 
+is proffered. (It was left to me and Steve to figure out, and I'm guessing 
+that Steve has had enough of inventing terms for a while. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 11, 2019  9:45 PM
+
+> I'm going to use "prepared" unless some obviously better idea is 
+> proffered. (It was left to me and Steve to figure out, and I'm 
+> guessing that Steve has had enough of inventing terms for a while. :-)
+
+It turns out that the "evaluation" of a value_sequence is that needed to 
+generate the values. We don't have anything about separately setting up 
+(evaluating the names) of the sequence anywhere.
+
+I looked into the possibility of separately defining the preparation of the 
+sequence, (or, even better, just elaborating it), but that wouldn't do 
+anything other than elaborate a subtype name or range (the actual iterator 
+name is evaluated as part of the dynamic semantics of iteration; we certainly 
+don't want to duplicate the dynamic semantics of container iteration).
+
+So, I conclude that the problem here is evaluating the value sequence first.
+It should simply be the last thing evaluated before we talk about what to do 
+with the values.
+
+This changes the offending paragraph to the following:
+
+   The evaluation of a use of this attribute begins by evaluating 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 an arbitrary order. It then initializes the /accumulator/ of the
+   reduction expression to the value of the /initial_value_/expression (the
+   /initial value/). The value_sequence V is then evaluated.
+
+It's a bit weird to evaluate the rightmost parts of the attribute first, but 
+we've already determined that the alternative doesn't make a lot of sense.
+And splitting out elaboration of an iterator_specification looks to be a lot 
+of wording change in 5.5.2; it hardly seems worth it.
+
+This change is a lot simpler than trying to invent a new term (or reuse an old
+term).
+
+Any complaints??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 11, 2019  9:51 PM
+
+No complaints from me.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent