CVS difference for 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