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

Differences between 1.19 and version 1.20
Log of other versions for file ai12s/ai12-0119-1.txt

--- ai12s/ai12-0119-1.txt	2018/06/16 03:03:27	1.19
+++ ai12s/ai12-0119-1.txt	2018/06/30 01:06:51	1.20
@@ -1,4 +1,4 @@
-!standard 5.5.2(2/3)                               18-06-10    AI12-0119-1/09
+!standard 5.5.2(2/3)                               18-06-23    AI12-0119-1/10
 !class Amendment 14-06-20
 !status work item 14-06-20
 !status received 14-06-17
@@ -7,8 +7,8 @@
 !subject Parallel operations
 !summary
 
-New syntax and semantics to facilitate parallelism via Parallel Loops and
-Parallel Blocks.
+We propose new syntax and semantics to facilitate parallelism via
+Parallel Loops and Parallel Blocks.
 
 !problem
 
@@ -34,121 +34,74 @@
 
 !proposal
 
-This proposal depends on the facilities for aspect Global (AI12-0079-1) and for
-aspect Nonblocking (AI12-0064-2). Those proposals allow the compiler to
-statically determine where parallelism may be introduced without introducing
-data races or deadlocking.
-
-This proposal informally introduces the semantic notion of a Parallel
-OPportunity (POP) and a tasklet to the language. POPs are places in program text
-where work can be distributed to parallel executing workers that work in concert
-to correctly execute the algorithm. Tasklets are the notional (logical) units
-within a task that are executed in parallel with each other.
-
-The goals of this proposal are:
-- To permit existing programs to benefit from parallelism through
-  minimal restructuring of sequential programs into ones that permit
-  more parallel execution;
-- To support the development of complete programs that maximize
-  parallelism;
-- To efficiently guide the compiler in the creation of effective
-  parallelism (without oversubscription of the parallelism resources) with
-  minimal input from the programmer;
-- To avoid syntax that would make a POP erroneous or produce noticeably
-  different results if executed sequentially vs in parallel.
-
-One issue to consider is the underlying runtime. In this model, tasklets are
-associated with tasks. Regardless of implementation, tasklets are
-considered to execute in the semantic context of the task where they
-have been spawned, which means that any operation that identifies a
-task, such as those in Task_Identification, will identify the task in
-which the tasklet is spawned. On the other hand, calls by different
-tasklets of the same task into the same protected object are treated as
-different calls resulting in distinct protected actions; therefore
-synchronization between tasklets can be performed using protected
-operations. Note that this is consistent with the current standard which
-already supports multiple concurrent calls by a single task in the
-presence of the asynchronous transfer of control capability
-(9.7.4 (23)).
-
-There are two areas of this proposal; one that introduce capabilities
-for parallel/concurrent blocks, and another that introduces capabilities for
-parallel loops. A third proposal that introduces capabilities for parallel
-reduction is covered in a separate AI, AI12-0242-1.
+We propose two parallel constructs, namely parallel blocks and parallel
+loops. A parallel block consists of a set of concurrent activities each
+specified by a handled sequence of statements, separated by the reserved
+word "and," analogous to the syntax for a select statement where the
+alternatives are separated by the reserved word "or."  A parallel loop
+defines a loop body which is designed such that the various iterations
+of the loop can run concurrently.  The implementation is expected to
+group the iterations into "chunks" to avoid creating an excessive number
+of physical threads of control, but each iteration is nevertheless
+considered for most purposes as its own separate logical thread of
+control.
+
+Both constructs start with the new reserved word "parallel" to clearly
+indicate that these constructs are designed for parallel execution.  The
+implementation might still not execute the constructs in parallel, but
+the intent is that if multiple processors are available, some or all
+of them should be allocated to the execution of the construct.
 
-Parallel Blocks
----------------
-
-Parallel blocks may be used to specify that two or more parts of an
-algorithm may be executed in parallel with each other.
-
-Semantics: A parallel block statement encloses two or more sequences of
-statements (two or more "parallel sequences") separated by the reserved
-word "and". Each parallel sequence represents a separate tasklet, but
-all within a single Ada task. Task identity remains that of the
-enclosing Ada task, and a single set of task attributes is shared
-between the tasklets. Each sequence of statements is assigned a unique
-and independent executor to execute the tasklet.
-
-With respect to the rules for shared variables (see 9.10(11-14), and
-specifically 9.10(13)), two actions occurring within two different parallel
-sequences of the same parallel block are not automatically sequential, so
-execution can be erroneous if one such action assigns to an object, and the
-other reads or updates the same object or a neighboring object that is not
-independently addressable from the first object. Potentially blocking
-operations are not allowed in a parallel sequence of a parallel block.
-Otherwise, the appropriate use of atomic, protected, or task objects (which as
-a group we will call synchronized objects) can be used to avoid erroneous execution.
-
-In addition, the new Global and Nonblocking aspects may be specified to enable
-the static detection of such problems at compile time (see AI12-0079-1 and
-AI12-0064-2).
-
-Any transfer of control out of one parallel sequence will initiate the
-aborting of the other parallel sequences not yet completed. Once all
-other parallel sequences complete normally or abort, the transfer of
-control takes place. If multiple parallel sequences attempt a transfer
-of control before completing, the first occurrence of transfer of control is
-selected and the others are aborted.
-
-The parallel block completes when all of the parallel sequences complete,
-either normally or by being aborted.
-
-Note that aborting a tasklet need not be preemptive, but should prevent
-the initiation of further nested parallel blocks or parallel loops.
-
-Parallel Loops
---------------
-
-A parallel loop is a loop where any iteration of the loop can execute in
-parallel with any other. There is no implied execution order for the iterations.
-Iterations that execute in parallel with other iterations are associated with
-different tasklets.
-
-To indicate that a loop is a candidate for parallelization, the reserved
-word "parallel" may be inserted immediately before the word "for" in a
-"for" loop.
-
-Note that the same rules presented for parallel blocks above also apply to
-the update of shared variables and the transfer of control to a point
-outside of the loop, and for this purpose each iteration can be considered
-as being equivalent to a separate sequence of a parallel block.
-
 !wording
 
 Add to the end of Introduction (28):
-  A parallel block statement comprises two or more sequences of
-  statements that should execute in parallel with each other. A parallel
-  loop statement has a loop body that is to be executed in parallel for
-  each iteration of the loop.
+  Various parallel constructs, including parallel loops and parallel blocks,
+  support the initiation of multiple logical threads of control designed
+  to execute in parallel when multipler processors are available.
 
 Modify 2.9(2/3):
   Add "parallel" to the list of reserved words.
 
+Add a sentence to the end of 5.1(1):
+
+  A /parallel construct/ is a construct that introduces additional
+  logical threads of control (see 9) without creating a new task.
+  Parallel loops (see 5.5) and parallel_block_statements (see
+  5.6.1) are parallel constructs.
+
 Modify 5.1(5/2):
 
   add "parallel_block_statement" to the list of compound statements.
 
+Add after 5.1(15):
+
+  Within a parallel construct, if a transfer of control out of the
+  construct is initiated by one of the logical threads of control, an
+  attempt is made to /cancel/ all other logical threads of control
+  initiated by the parallel construct. Once all other logical threads of
+  control of the construct either complete or are canceled, the transfer
+  of control occurs.  If two or more logical threads of control of the
+  same construct initiate such a transfer of control concurrently, one
+  of them is chosen arbitrarily and the others are canceled.
+
+  When a logical thread of control is canceled, it causes it to complete
+  as though it had performed a transfer of control to the point where it
+  would have finished its execution.  Such a cancellation is deferred
+  while it is executing within an abort-deferred operation (see 9.8),
+  and may be deferred further, but not past a point where the logical
+  thread initiates a new nested parallel construct, or reaches an
+  exception handler.
+
+  Bounded (Run-Time) Errors
+
+  During the execution of a parallel construct, it is a bounded error to
+  invoke an operation that is potentially blocking (see 9.5).
+  Program_Error is raised if the error is detected by the
+  implementation; otherwise, the execution of the potentially blocking
+  operation might proceed normally, or it might result in the indefinite
+  blocking of some or all of the logical threads of control making up
+  the current task.
+
 Replace 5.5(3/3):
 
 Iteration_scheme ::= while condition
@@ -157,7 +110,7 @@
 
 Add after 5.5(6/5):
 
-  [editor: still part of syntax rules]
+  [editor: this rule is still part of the syntax rules]
   An iteration_scheme that begins with the reserved word parallel shall
   not have the reserved word reverse in its loop_parameter_specification.
 
@@ -191,51 +144,34 @@
 
 Add after 5.5(9/4):
 
-  Within a parellel loop, if a transfer of control out of the loop is
-  initiated by one of the iterations, an attempt is made to cancel all
-  other iterations of the loop. Once all other iterations of the loop
-  either complete or are canceled, the transfer of control occurs.  If
-  two or more iterations initiate such a transfer of control
-  concurrently, one of them is chosen arbitrarily and the others are
-  canceled.
-
   AARM Implementation note: -- Each iteration of a parallel loop is a
   separate logical thread of control.  Normally these logical threads of
   control will be grouped into "chunks" for the purpose of execution to
   reduce the cost of creating large numbers of (physical) threads of
   control.
 
-Add after 5.5(9.1/3):
-
-  Bounded (Run-Time) Errors
-
-  During the execution of one of the iterations of a parallel loop, it
-  is a bounded error to invoke an operation that is potentially blocking
-  (see 9.5).
-
 Add after 5.5(21):
 
   Example of a parallel loop:
 
   -- See 3.6(30/2)
-  parallel
-  for I in Grid(1)'Range loop
-     Grid(I, 1) := (for all J in Grid(2)'Range => Grid(I,J) = True);
+  parallel for I in Grid'Range(1) loop
+     Grid(I, 1) := (for all J in Grid'Rang(2)e => Grid(I,J) = True);
   end loop;
 
-Add a new subclause
+Add a new subclause:
 
 5.6.1 Parallel Block Statements
 
-A parallel_block_statement encloses two or more
-handled_sequence_of_statements where each represents a separate logical
-thread of control.
+A parallel_block_statement comprises two or more
+handled_sequence_of_statements separated by *and* where each represents
+an independent activity that is intended to proceed concurrently with
+the others.
 
 Syntax
 
   parallel_block_statement ::=
-    parallel
-    do
+    parallel do
       handled_sequence_of_statements
     and
       handled_sequence_of_statements
@@ -246,22 +182,11 @@
 Static Semantics
 
 Each handled_sequence_of_statements represents a separate logical thread
-of control that proceeds independently and concurrently between the
-points where they interact with other logical threads of control.
-
-The execution of a parallel_block_statement consists of the concurrent
-execution of the handled_sequence_of_statements. The
+of control that proceeds independently and concurrently. The
 parallel_block_statement is complete once every one of the
-handled_sequence_of_statements has completed, either by reaching the end
-of its execution, or due to a transfer of control out of the construct
-by one of the handled_sequence_of_statements. When a transfer of control
-to a point outside the construct is initiated by one of the
-handled_sequence_of_statements, an attempt is made to cancel all of the
-other handled_sequence_of_statements.  Once all of these either reach
-the end of their execution or are canceled, the transfer of control
-occurs.  If two or more of the handled_sequence_of_statements initiate
-such a transfer of control concurrently, one of them is chosen
-arbitrarily and the others are canceled.
+handled_sequence_of_statements has completed, either by reaching the end of its
+execution, or due to a transfer of control out of the construct by one of the
+handled_sequence_of_statements (see 5.1).
 
 AARM Implementation Note -- Each handled_sequence_of_statements of a parallel
 block is a separate logical thread of control.  The implementation may
@@ -269,45 +194,56 @@
 physical thread of control to reduce the cost of creating numerous physical
 threads of control.
 
-Bounded (Run-Time) Errors
-
-During the execution of one of the handled_sequence_of_statements of a
-parallel_block_statement, it is a bounded error to invoke an operation that is
-potentially blocking (see 9.5).
-
 Examples
-
-Example of a parallel block statement:
 
-   do
-     Foo(Z);
-   and
-     Bar(X, Y);
-   and
-     Put_Line ("Executing Foo and Bar in parallel with Other_Work");
-     Other_Work;
-     exception
-        when Constraint_Error =>
-          Put_Line ("Constraint Error raised doing Other_Work");
-   end do;
+   procedure Traverse
+     (T : Expr_Ptr) --  see 3.9
+   is
+   begin
+     if T /= null
+       and then
+        T.all in Binary_Operation'Class -- see 3.9.1
+     then -- recurse down the binary tree
+       parallel do
+         Traverse (T.Left);
+       and
+         Traverse (T.Right);
+       and
+         Ada.Text_IO.Put_Line
+           ("Processing " & Ada.Tags.Expanded_Name (T'Tag));
+       end do;
+     end if;
+   end Traverse;
 
-   function Fibonacci (N : Natural) return Natural is
-      X, Y : Natural;
+   function Search (S : String; Char : Character) return Boolean is
    begin
-      if N < 2 then
-         return N;
+      if S'Length <= 1000 then
+          -- Sequential scan
+          return (for some C of S => C = Char);
+      else
+          -- Parallel divide and conquer
+          declare
+            Mid : constant Positive := S'First + S'Length/2 - 1;
+          begin
+            parallel do
+              for C of S(S'First .. Mid) loop
+                 if C = Char then
+                    return True;  --  Terminates enclosing "do"
+                 end if;
+              end loop;
+            and
+             for C of S(Mid + 1 .. S'Last) loop
+                 if C = Char then
+                    return True;  --  Terminates enclosing "do"
+                 end if;
+              end loop;
+            end do;
+            --  Not found
+            return False;
+          end;
       end if;
+   end Contains;
 
-      parallel
-      do
-        X := Fibonacci (N - 2);
-      and
-        Y := Fibonacci (N - 1);
-      end do;
-
-      return X + Y;
-   end Fibonacci;
-
 Modify 9(1/3):
 
   The execution of an Ada program consists of the execution of one or
@@ -367,38 +303,17 @@
 
 !discussion
 
-There is a continuing trend of exponential growth of computational
-elements embedded on a single chip. This has led to significant
-challenges for software designers and implementers. Prior to 2005, the
-increase in transistor count corresponded to a similar increase in CPU
-clock speed, which boosted performance of sequential algorithms. Since
-then, CPU clock speeds have leveled off for reasons of practicality, and
-chip manufacturers have instead moved towards multicore technologies as
-a means of achieving performance increases.
-
-As parallel technologies become more prevalent in the form of new
-emerging hardware platforms, safety concerns need to consider the
-paradigm shift from sequential to parallel behaviour.  It is a paradigm
-that has been for a long time contained within a specialized domain of
-high-performance computing, but that is now required in all domains of
-computing systems.
-
-It is important for the programmer to indicate places in the code
+It is important for the programmer to be able to indicate places in the code
 where parallelism is desired, which allows the reader to better
 understand the algorithm, and allows the programmer to receive
-confirmation from the compiler whether the desired parallelism is safe,
-or even worthwhile.
+confirmation from the compiler whether the desired parallelism is safe.
 
-This proposed model does not define syntax for the explicit
-parallelization of individual subprogram calls, since such
-parallelization can be performed implicitly by the compiler, when it
-knows that the calls are free of side-effects. This is facilitated by
-annotations identifying global variable usage on subprogram
-specifications (see AI12-0079-1). Furthermore, a single subprogram call
-is rarely the best unit of parallelism. More frequently there is some
-setup and/or some post-call actions that should be grouped with the
-call, so the parallel block notation was felt the more appropriate way to
-perform a "parallel" call.
+This proposed model does not define syntax for the explicit parallel
+invocation of an individual subprogram call, since a single subprogram
+call is rarely the best unit of parallelism. More frequently there is
+some setup and/or some post-call actions that should be grouped with the
+call, so the parallel block notation was felt the more appropriate way
+to perform a "parallel" call.
 
 Parallel Blocks
 ---------------
@@ -421,8 +336,8 @@
       end;
 
 In this example, the calculation of Z and Y occur sequentially with
-respect to each other, but in parallel with the calculation of X. Note
-that the compiler, using the rules specified in AI12-0079-1, may
+respect to each other, but concurrently with the calculation of X. Note
+that the compiler, using the rules specified in AI12-0267-1, may
 complain if the parallel sequences might have conflicting global
 side-effects, or if the parallel sequences might have Potentially Blocking
 operations.
@@ -456,17 +371,7 @@
 sequences to outlive the parallel block. Therefore we reverted to the
 simpler syntax proposed above. Because there are no local declarations,
 there was also no point in having a statement_identifier (block label)
-for a parallel block. Allowing an exit statement to replace a goto that
-targets the location following the end of the parallel block statement
-seems useful, and to allow such a statement, a block label might be
-needed to identify the parallel block that is being exited. However,
-allowing exit statements is problematic for the same reason that exit
-statements are not currently allowed in block statements. It could be
-confusing if an exit occurred within a loop enclosed by the parallel
-block. Some might see it as syntax to exit the loop, others might see it
-as syntax to exit the parallel block. Rather than deal with this now, it
-was felt that if there was strong enough of a need for allowing an exit
-statement in a parallel block, it could be the subject of a separate AI.
+for a parallel block.
 
 We considered what the semantics might be for a parallel block if the
 parallel keyword were absent. This might be a good syntactic construct
@@ -500,7 +405,7 @@
 arrays together to produce a result array:
 
   parallel
-  for I in Loop_Iterations'Range loop
+  for I in Result'Range loop
     Result (I)  := A(I) + B(I);
   end loop;
 
@@ -517,18 +422,14 @@
 compiler, using the rules specified in AI12-0079-1, may complain if the
 parallel sequences might have conflicting access to shared variables.
 We don't define such rules in this AI.
+
+Note that there are other AIs that address the issues of incorporating
+a reduction operation with a parallel iterator (see AI12-0262-1) and
+with providing more control over "chunking" of parallel loops (see
+AI12-0251-1/2).
 
-We considered extending the syntax to allow reductions to be performed
-with parallel loops, but we discovered that parallel reduction
-expressions can provide the same capability more concisely, so for now
-we allow parallel loops to work if there are no global conflicts. A
-separate AI could be created to add reduction loop capability if it is
-decided that this is needed. In the meantime, Reduction Expressions
-appear to better fill this need. The main purpose of a loop is to apply
-processing iteratively. The main purpose of a reduction however, is to
-generate a result value. Iteration is a means to achieve that end, but a
-reduction expression seems better suited since it is designed to produce
-a result value.
+AI12-0267-1 provides rules to check for blocking operations
+and for race conditions within parallel constructs.
 
 !ASIS
 
@@ -7173,80 +7074,80 @@
 From: Tucker Taft
 Sent: Tuesday, June 12, 2018  8:34 AM
 
-> Here is a significant revision of the Parallel Operations AI. 
-> 
-> As usual, I fixed a number of typos in it while posting: a number of 
-> colons were missing (you added many that were missing, but missed a 
-> few), a couple of spelling errors (like "modfiy"), and I got rid of 
-> the extra spaces after periods that some of us were taught to include 
+> Here is a significant revision of the Parallel Operations AI.
+>
+> As usual, I fixed a number of typos in it while posting: a number of
+> colons were missing (you added many that were missing, but missed a
+> few), a couple of spelling errors (like "modfiy"), and I got rid of
+> the extra spaces after periods that some of us were taught to include
 > on a typewriter, but never have been used in AIs.
 
 Good luck taking that second space out of my fingers' typing reflexes...
 
->> I dropped the use of terms like "tasklet" and "executor" and used 
+>> I dropped the use of terms like "tasklet" and "executor" and used
 >> "logical thread of control" more widely.
-> 
+>
 > The wording wasn't long enough already? ;-)
-> 
-> I guess I would have expected to use some short term for this, as it 
+>
+> I guess I would have expected to use some short term for this, as it
 > is going to need to be frequently referenced in AIs, discussions, and
-> (especially) educational material. I'm already exhausted of writing 
-> "logical thread of control", and there isn't even a pronouncable 
-> acronym for it (LToC isn't that). There's 18 occurrences in this AI, 
+> (especially) educational material. I'm already exhausted of writing
+> "logical thread of control", and there isn't even a pronouncable
+> acronym for it (LToC isn't that). There's 18 occurrences in this AI,
 > and I presume there will be more in the related AIs.
 
-For now, I think it is worth being explicit.  Once we all agree on the term, 
+For now, I think it is worth being explicit.  Once we all agree on the term,
 we can consider an "official" short hand.
 
-> I realize that it is clearer in some sense, 'cause there's no chance 
-> of confusion, as there might be just calling it a "thread". Maybe just 
+> I realize that it is clearer in some sense, 'cause there's no chance
+> of confusion, as there might be just calling it a "thread". Maybe just
 > shorten it to "logical thread" except in 9(1)?
 
-That seems reasonable, but again, I'd rather wait on that until we get a 
+That seems reasonable, but again, I'd rather wait on that until we get a
 chance to review this AI together.
- 
-> In any case, if we're not going to use "tasklet", the !proposal needs 
-> to be rewritten to purge the term. It ought not be used outside of the 
+
+> In any case, if we're not going to use "tasklet", the !proposal needs
+> to be rewritten to purge the term. It ought not be used outside of the
 > "reject options" discussion (which you already have).
 
-That makes sense.  Just not a priority at the moment until we all agree on 
+That makes sense.  Just not a priority at the moment until we all agree on
 the new terminology.
 
->> I tried to simplify the rules as far as I could, to avoid 
+>> I tried to simplify the rules as far as I could, to avoid
 >> over-specification, and because simple is usually good.
 >> Comments welcome!
-> 
-> Overall the wording looks good. I didn't see anything that didn't make 
+>
+> Overall the wording looks good. I didn't see anything that didn't make
 > sense, but I didn't try very hard to look for omissions.
 
 Very glad to hear that.  Thanks for the review.  I hope others will have time
 to review it as well before the meeting...
 
->> Note that the !proposal is essentially unchanged, and only a bit was 
->> added to the !discussion.  So I recommend folks start with the 
->> revised !wording rather than wading through the other material which 
+>> Note that the !proposal is essentially unchanged, and only a bit was
+>> added to the !discussion.  So I recommend folks start with the
+>> revised !wording rather than wading through the other material which
 >> really hasn't changed much.
-> 
-> I usually use a file compare to read updated AIs, not always the best 
-> idea but it works great when a lot of the discussion material is 
+>
+> I usually use a file compare to read updated AIs, not always the best
+> idea but it works great when a lot of the discussion material is
 > little changed.
 
-Unfortunately, I often end up re-formatting paragraphs a bit to make 
+Unfortunately, I often end up re-formatting paragraphs a bit to make
 line-lengths reasonable and most file compares aren't good at handling
 that. The side-by-side comparison used by "gerrit" seems pretty good at
-that -- I don't know if there are other such tools available for more 
+that -- I don't know if there are other such tools available for more
 stand-alone use.
 
 >> We don't define such rules in this AI.
-> 
+>
 > Shouldn't we at least mention that such rules are proposed in another AI?
 > (AI12-0267-1 in particular).
 
-I suppose, but I am still working on that one, and predicting what it will 
+I suppose, but I am still working on that one, and predicting what it will
 look like is a bit difficult until I at least have a first draft!
 
-> It might also make sense to mention the reduction expression AIs 
-> (AI12-0242-1, AI12-0262-1) in the discussion on that topic (rather 
+> It might also make sense to mention the reduction expression AIs
+> (AI12-0242-1, AI12-0262-1) in the discussion on that topic (rather
 > than just leading the reader hanging).
 
 I suppose.  Again, it just wasn't a priority yet.
@@ -7257,67 +7158,67 @@
 Sent: Tuesday, June 12, 2018  6:24 PM
 
 ...
-> > As usual, I fixed a number of typos in it while posting: a number of 
-> > colons were missing (you added many that were missing, but missed a 
-> > few), a couple of spelling errors (like "modfiy"), and I got rid of 
-> > the extra spaces after periods that some of us were taught to 
+> > As usual, I fixed a number of typos in it while posting: a number of
+> > colons were missing (you added many that were missing, but missed a
+> > few), a couple of spelling errors (like "modfiy"), and I got rid of
+> > the extra spaces after periods that some of us were taught to
 > > include on a typewriter, but never have been used in AIs.
-> 
-> Good luck taking that second space out of my fingers' typing 
+>
+> Good luck taking that second space out of my fingers' typing
 > reflexes...
 
-I've pretty much given up on it, but since I was mentioning changes "for 
+I've pretty much given up on it, but since I was mentioning changes "for
 the record", I figured I better mention that.
 
 ...
-> > In any case, if we're not going to use "tasklet", the !proposal 
-> > needs to be rewritten to purge the term. It ought not be used 
+> > In any case, if we're not going to use "tasklet", the !proposal
+> > needs to be rewritten to purge the term. It ought not be used
 > > outside of the "reject options" discussion (which you already have).
-> 
-> That makes sense.  Just not a priority at the moment until we all 
+>
+> That makes sense.  Just not a priority at the moment until we all
 > agree on the new terminology.
 
-Understood. However, I'd hope that we can wrap up this AI at our upcoming 
-meeting (since many other things depend on it, it's hard to make progress 
+Understood. However, I'd hope that we can wrap up this AI at our upcoming
+meeting (since many other things depend on it, it's hard to make progress
 without it being done -- and it appears mostly done to me), which would put
 that update into the hands of our overworked and overbudget editor. Which I'd
 like to avoid. :-)
 
 ...
-> >> Note that the !proposal is essentially unchanged, and only a bit 
-> >> was added to the !discussion.  So I recommend folks start with the 
-> >> revised !wording rather than wading through the other material 
+> >> Note that the !proposal is essentially unchanged, and only a bit
+> >> was added to the !discussion.  So I recommend folks start with the
+> >> revised !wording rather than wading through the other material
 > >> which really hasn't changed much.
-> > 
-> > I usually use a file compare to read updated AIs, not always the 
-> > best idea but it works great when a lot of the discussion material 
+> >
+> > I usually use a file compare to read updated AIs, not always the
+> > best idea but it works great when a lot of the discussion material
 > > is little changed.
-> 
-> Unfortunately, I often end up re-formatting paragraphs a bit to make 
+>
+> Unfortunately, I often end up re-formatting paragraphs a bit to make
 > line-lengths reasonable and most file compares aren't
-> good at handling that.   The side-by-side comparison used by 
-> "gerrit" seems pretty good at that -- I don't know if there are other 
+> good at handling that.   The side-by-side comparison used by
+> "gerrit" seems pretty good at that -- I don't know if there are other
 > such tools available for more stand-alone use.
 
-I tend to reformat both sides to match when I do that -- which is why the 
-result often ends up with different line breaks than you sent. (If I have 
-to edit something, I tend to start with the reformatted version and not 
+I tend to reformat both sides to match when I do that -- which is why the
+result often ends up with different line breaks than you sent. (If I have
+to edit something, I tend to start with the reformatted version and not
 your original text.)
 
 > >> We don't define such rules in this AI.
-> > 
+> >
 > > Shouldn't we at least mention that such rules are proposed in another AI?
 > > (AI12-0267-1 in particular).
-> 
-> I suppose, but I am still working on that one, and predicting what it 
+>
+> I suppose, but I am still working on that one, and predicting what it
 > will look like is a bit difficult until I at least have a first draft!
 
 Sure, but it's the cross reference that's valuable, not the details.
 
-> > It might also make sense to mention the reduction expression AIs 
-> > (AI12-0242-1, AI12-0262-1) in the discussion on that topic (rather 
+> > It might also make sense to mention the reduction expression AIs
+> > (AI12-0242-1, AI12-0262-1) in the discussion on that topic (rather
 > > than just leading the reader hanging).
-> 
+>
 > I suppose.  Again, it just wasn't a priority yet.
 
 Same here.
@@ -7336,10 +7237,17 @@
 But the consequences of the Bounded Error are missing here. We always have
 to say what happens with a bounded error. We need a sentence like:
 
-If the bounded error is detected, Program_Error is raised. If not detected, 
-blocking of the logical thread of control may occur as defined elsewhere in 
+If the bounded error is detected, Program_Error is raised. If not detected,
+blocking of the logical thread of control may occur as defined elsewhere in
 this standard, possibly leading to deadlock.
 
 The second bounded error needs some similar text.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Saturday, June 23, 2018  6:31 PM
+
+Here is an update. [This is version /10 of the AI - Editor.]
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent