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

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

--- ai12s/ai12-0119-1.txt	2018/06/12 01:43:50	1.18
+++ ai12s/ai12-0119-1.txt	2018/06/16 03:03:27	1.19
@@ -7169,3 +7169,177 @@
 reader hanging).
 
 ***************************************************************
+
+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 
+> 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 
+>> "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 
+> 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, 
+> 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, 
+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 
+> shorten it to "logical thread" except in 9(1)?
+
+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 
+> "reject options" discussion (which you already have).
+
+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 
+>> over-specification, and because simple is usually good.
+>> Comments welcome!
+> 
+> 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 
+>> 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 
+> little changed.
+
+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 
+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 
+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 
+> than just leading the reader hanging).
+
+I suppose.  Again, it just wasn't a priority yet.
+
+***************************************************************
+
+From: Randy Brukardt
+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 
+> > include on a typewriter, but never have been used in AIs.
+> 
+> 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 
+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 
+> > 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 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 
+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 
+> >> 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 little changed.
+> 
+> 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 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 
+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 
+> 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 
+> > than just leading the reader hanging).
+> 
+> I suppose.  Again, it just wasn't a priority yet.
+
+Same here.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 12, 2018  7:40 PM
+
+I just noticed that you have bounded error text like:
+
+  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).
+
+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 
+this standard, possibly leading to deadlock.
+
+The second bounded error needs some similar text.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent