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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0294-1.txt

--- ai12s/ai12-0294-1.txt	2018/11/27 05:34:51	1.2
+++ ai12s/ai12-0294-1.txt	2018/12/05 01:52:15	1.3
@@ -1,4 +1,4 @@
-!standard 3.3(23/3)                                     18-11-15  AI12-0294-1/01
+!standard 3.3(23/3)                                     18-11-27  AI12-0294-1/02
 !standard 5.5(8)
 !standard 5.5(9/5)
 !standard 5.5(9.1/5)
@@ -114,6 +114,15 @@
   order unless the reserved word reverse is present, in which case the
   values are assigned in decreasing order.
 
+     AARM To Be Honest: This wording does not describe when the loop parameter
+     object(s) are created. That creation has no side-effects (other than 
+     possibly raising Storage_Error, but anything can do that), so we 
+     simplified the wording by leaving it out. Each object has to be created
+     before any iteration that depends on it starts, but we do not (for
+     instance) require that the objects are all created at once at the start
+     of the loop, nor that the objects are created after the elaboration of the 
+     discrete_subtype_definition.
+
   If a chunk_specification with a discrete_subtype_definition is present,
   then the logical thread of control associated with a given chunk has its
   own copy of the chunk parameter initialized with a distinct value from
@@ -122,6 +131,7 @@
   increasing values of the ranges covered by the corresponding loop
   parameters.
 
+Delete AARM 5.5(9.a) (it is effectively replaced by the AARM note given above)
 
 !discussion
 
@@ -600,3 +610,210 @@
 associated iteration starts. Or something like that. Thoughts?
 
 ***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 27, 2018  9:29 AM
+
+> One last thought on this rewording. Nowhere in this wording do we say 
+> when the loop parameter (or parameters) are created. That isn't very 
+> important (as there is no side-effects from such creation, as noted by 
+> an AARM Note), but it still seems strange. I wondered if we need a To 
+> Be Honest AARM note to say that we don't describe exactly when each 
+> loop parameter is created, since it doesn't have any visible effect, 
+> but it does have to be done before the associated iteration starts. Or 
+> something like that. Thoughts?
+
+TBH sounds like the right solution.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 27, 2018  9:27 AM
+
+> Thanks for the wording.
+> 
+> Three minor quibbles.
+> 
+> First, you have "(a /parallel/ loop)". But the term we're defining 
+> here is "parallel loop", not just parallel. So the italics should 
+> include "loop" -- that is "(a /parallel loop/)". The same applies to
+> "sequential loop".
+
+Fine.
+
+> 
+> Second, you dropped part of the introduction, specifically "For [the 
+> execution of] a loop_statement..." The "the execution of" part seems 
+> needed to be consistent with the wording in the rest of the clause. 
+> (See while loops and unconditional loops).
+
+Yes I dropped it because it didn't seem to make sense any more.
+ 
+> I presume you dropped it because it is weirdish to talk about 
+> elaboration of a chunk_specification before describing any part of the 
+> execution of a loop.
+> However, I've convinced myself that it is OK, as the elaboration of a 
+> chunk_specification applies to a number of kinds of loops (it's 
+> supposed to apply to the "of" form loops, I think; Brad needs to 
+> include that in his
+> AI12-0266-1 if it isn't there yet). While the following paragraph 
+> applies only to the execution of one kind of loop.
+> 
+> (Side note: splitting that paragraph into a paragraph that is general, 
+> and a paragraph that talks about loop parameters, should help out 
+> Brad, because he only wants the first part anyway.)
+
+OK.  I am not sure what you are saying here -- perhaps if I saw your rewording 
+it would be obvious.
+
+> Third, a number of terms that were previously syntax terms lost their 
+> underscores. I put them back, seeing no reason to make unnecessary changes.
+
+Make sense.
+ 
+> I won't mention that a number of sentences end with an pair of blanks, 
+> and others with a single blank. :-)
+
+Yes, let's not mention that... ;-)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 27, 2018  8:22 PM
+
+...
+> > Second, you dropped part of the introduction, specifically "For [the 
+> > execution of] a loop_statement..." The "the execution of" part seems 
+> > needed to be consistent with the wording in the rest of the clause.
+> > (See while loops and unconditional loops).
+> 
+> Yes I dropped it because it didn't seem to make sense any more.
+
+In a vacuum, surely. In the context of the entire Dynamic Semantics section
+for this subclause, it seems wrong without it (there then would be no 
+explanation of the execution of standard for loops, but there is for while 
+loops and plain loops).
+
+> > I presume you dropped it because it is weirdish to talk about 
+> > elaboration of a chunk_specification before describing any part of 
+> > the execution of a loop.
+> > However, I've convinced myself that it is OK, as the elaboration of 
+> > a chunk_specification applies to a number of kinds of loops (it's 
+> > supposed to apply to the "of" form loops, I think; Brad needs to 
+> > include that in his
+> > AI12-0266-1 if it isn't there yet). While the following paragraph 
+> > applies only to the execution of one kind of loop.
+> > 
+> > (Side note: splitting that paragraph into a paragraph that is 
+> > general, and a paragraph that talks about loop parameters, should 
+> > help out Brad, because he only wants the first part anyway.)
+> 
+> OK.  I am not sure what you are saying here -- perhaps if I saw your 
+> rewording it would be obvious.
+
+The above is confusing. I was just pointing out that most of the wording 
+for chunk_specifications should apply to all kinds of parallel loops (the
+elaboration, meaning in terms of chunks, and the check for nonzero all 
+apply to all parallel for loops), while the rules about the loop parameter
+only apply to discrete "in" for loops. "of" loops don't even have loop 
+parameters per-se, and "in" cursor loops have their own set of rules for
+managing the loop parameters. In particular, none of those other loop types
+have ordering for their parameters, so talking about "non-overlap" and 
+"increasing order" is nonsense for them. (Maybe the array loop can talk about
+that in terms of the index, but the others get their chunks from the 
+user-defined interface that we've been polishing over the last several 
+meetings.)
+
+I'm certain that ultimately we intend to have parallel versions of all four 
+kinds of "for" loops, even though this AI (and AI12-0119-1 before it) only 
+contemplates parallel discrete "in" for loops. Brad supposedly is defining 
+those other kinds of loops in AI12-0266-1; the less he has to modify this 
+(AI12-0251-1/AI12-0294-1) wording in order to do that sensibly, the better 
+off we'll be. (It would be madness to not have chunk_specifications on those
+other kinds of loops, so I'm not even considering that.)
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 27, 2018  8:55 PM
+
+> ...
+>>> Second, you dropped part of the introduction, specifically "For [the 
+>>> execution of] a loop_statement..." The "the execution of" part seems 
+>>> needed to be consistent with the wording in the rest of the clause.
+>>> (See while loops and unconditional loops).
+>> 
+>> Yes I dropped it because it didn't seem to make sense any more.
+> 
+> In a vacuum, surely. In the context of the entire Dynamic Semantics 
+> section for this subclause, it seems wrong without it (there then 
+> would be no explanation of the execution of standard for loops, but 
+> there is for while loops and plain loops).
+
+It may be that we can just sneak in the "For the execution of a ... at the 
+beginning of the second paragraph.
+
+>>> I presume you dropped it because it is weirdish to talk about 
+>>> elaboration of a chunk_specification before describing any part of 
+>>> the execution of a loop.
+>>> However, I've convinced myself that it is OK, as the elaboration of 
+>>> a chunk_specification applies to a number of kinds of loops (it's 
+>>> supposed to apply to the "of" form loops, I think; Brad needs to 
+>>> include that in his
+>>> AI12-0266-1 if it isn't there yet). While the following paragraph 
+>>> applies only to the execution of one kind of loop.
+>>> 
+>>> (Side note: splitting that paragraph into a paragraph that is 
+>>> general, and a paragraph that talks about loop parameters, should 
+>>> help out Brad, because he only wants the first part anyway.)
+>> 
+>> OK.  I am not sure what you are saying here -- perhaps if I saw your 
+>> rewording it would be obvious.
+> 
+> The above is confusing.
+
+Perhaps you were saying that it is good that I *already* split it up into 
+multiple paragraphs.  At first I presumed you wanted it to be split further,
+but maybe you are simply acknowledging that the split I proposed is useful 
+for other reasons as well.
+
+> I was just pointing out that most of the wording for 
+> chunk_specifications should apply to all kinds of parallel loops (the 
+> elaboration, meaning in terms of chunks, and the check for nonzero all 
+> apply to all parallel for loops), while the rules about the loop 
+> parameter only apply to discrete "in" for loops. "of" loops don't even 
+> have loop parameters per-se, and "in" cursor loops have their own set 
+> of rules for managing the loop parameters. In particular, none of 
+> those other loop types have ordering for their parameters, so talking 
+> about "non-overlap" and "increasing order"
+> is nonsense for them. (Maybe the array loop can talk about that in 
+> terms of the index, but the others get their chunks from the 
+> user-defined interface that we've been polishing over the last several 
+> meetings.)
+> 
+> I'm certain that ultimately we intend to have parallel versions of all 
+> four kinds of "for" loops, even though this AI (and AI12-0119-1 before 
+> it) only contemplates parallel discrete "in" for loops. Brad 
+> supposedly is defining those other kinds of loops in AI12-0266-1; the 
+> less he has to modify this
+> (AI12-0251-1/AI12-0294-1) wording in order to do that sensibly, the 
+> better off we'll be. (It would be madness to not have 
+> chunk_specifications on those other kinds of loops, so I'm not even 
+> considering that.)
+
+Agreed.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 27, 2018  9:07 PM
+
+...
+> It may be that we can just sneak in the "For the execution of a ... at 
+> the beginning of the second paragraph.
+
+That's what I did. Not sure if the rest makes complete sense with that 
+added, but that's why we review what I do at meetings. :-)
+
+***************************************************************
+

Questions? Ask the ACAA Technical Agent