CVS difference for ai12s/ai12-0418-1.txt
--- ai12s/ai12-0418-1.txt 2020/12/17 09:01:19 1.1
+++ ai12s/ai12-0418-1.txt 2021/01/09 08:01:46 1.2
@@ -1,4 +1,4 @@
-!standard 9.7.4(14/4) 20-12-14 AI12-0418-1/01
+!standard 9.7.4(14/4) 21-01-08 AI12-0418-1/02
!class binding interpretation 20-12-14
!status Amendment 1-2012 20-12-14
!status work item 20-12-14
@@ -21,6 +21,8 @@
two other clauses have commas before "Legality Rules" so this one is
inconsistent. Should it be added? (Yes.)
+(3) 5.5.2(10.2/5) uses commas oddly, and is hard to read because of its
+size. Should the comma use be improved, and the paragraph split? (Yes.)
!recommendation
@@ -28,12 +30,47 @@
(2) Add the comma.
+(3) Add one comma, remove two others, replace "having" with "that has" (2
+places), and split into three parts.
+
!wording
[Editor's note: These changes were applied to Draft 28 of the Ada 202x RM,
even though they have not yet been approved, in order that that draft be as
accurate as possible.]
+Modify 5.5.2(10.2/5): [This splits it into three parts, and makes other
+changes as noted:]
+
+Upon return from Split_Into_Chunks, the actual number of chunks for the loop
+is determined by calling the Chunk_Count operation of the iterator, at which
+point one logical thread of control is initiated for each chunk, with an
+associated chunk index in the range from one to the actual number of chunks.{
+
+}Within each logical thread of control, a loop parameter is created. If a
+chunk_specification with a discrete_subtype_definition is present in the
+associated parallel construct, then a chunk parameter is created[,] and
+initialized with a value from the discrete subtype defined by the
+discrete_subtype_definition, so that the order of the chosen chunk parameter
+values correspond to the order of the chunk indices associated with the
+logical threads of control. The operation First of the iterator type {that
+has}[having] a Chunk parameter is called on the loop iterator, with Chunk
+initialized from the corresponding chunk index, to produce the initial value
+for the loop parameter. If the result of calling Has_Element on this initial
+value is False, then the execution of the logical thread of control is
+complete. Otherwise, the sequence_of_statements is conditionally executed{,}
+and then the Next operation of the iterator type {that has}[having] a Chunk
+parameter is called[,] with the loop iterator, the current value of the loop
+parameter, and the corresponding chunk index, to produce the next value to be
+assigned to the loop parameter. This repeats until the result of calling
+Has_Element on the loop parameter is False, or the associated parallel
+construct is left as a consequence of a transfer of control.{
+
+}In the absence of a transfer of control, the associated parallel construct
+of a parallel generalized iterator is complete when all of its logical threads
+of control are complete.
+
+
Modify 9.7.4(14/4):
Note that these examples presume that there are abort completion points
@@ -53,6 +90,26 @@
(See !recommendation.)
+!corrigendum 5.5.2(10/3)
+
+@drepl
+For a generalized iterator, the loop parameter is created, the
+@i<iterator_>@fa<name> is evaluated, and the denoted iterator object becomes
+the @i<loop iterator>. In a forward generalized iterator, the operation
+First of the iterator type is called on the loop iterator, to produce
+the initial value for the loop parameter. If the result of calling
+Has_Element on the initial value is False, then the execution of the
+@fa<loop_statement> is complete. Otherwise, the @fa<sequence_of_statements>
+is executed and then the Next operation of the iterator type is called with
+the loop iterator and the current value of the loop parameter to produce the
+next value to be assigned to the loop parameter. This repeats until
+the result of calling Has_Element on the loop parameter is False,
+or the loop is left as a consequence of a transfer of control. For a
+reverse generalized iterator, the operations Last and Previous are
+called rather than First and Next.
+@dby
+*** The replacement text is found in the conflict file ***
+
!corrigendum 9.7.4(14/4)
@drepl
@@ -102,3 +159,362 @@
****************************************************************
+From the AARM review of Justin Squirek, October 2020
+
+-----------
+-- 5.5.2 --
+-----------
+
+10.2/5: This section reads strangely to me and many commas seem out of place
+(I could be wrong though). I have included the entire section here with
+suggested improvements surrounded by square brackets:
+
+"Upon return from Split_Into_Chunks, the actual number of chunks for the loop
+is determined by calling the Chunk_Count operation of the iterator, at which
+point one logical thread of control is initiated for each chunk [removed
+comma] with an associated chunk index in the range from one to the actual
+number of chunks. Within each logical thread of control [removed comma] a loop
+parameter is created. If a chunk_specification with a
+discrete_subtype_definition is present in the associated parallel construct,
+then a chunk parameter is created [removed comma] and initialized with a
+value from the discrete subtype defined by the discrete_subtype_definition,
+so that the order of the chosen chunk parameter values correspond to the order
+of the chunk indices associated with the logical threads of control. The
+operation First of the iterator type [containing] a Chunk parameter [gets]
+called on the loop iterator, with Chunk initialized from the corresponding
+chunk index, to produce the initial value for the loop parameter. If the
+result of calling Has_Element on this initial value is False, then the
+execution of the logical thread of control is complete. Otherwise, the
+sequence_of_statements is conditionally executed and then the Next operation
+of the iterator type [containing] a Chunk parameter [gets] called [comma
+removed] with the loop iterator, the current value of the loop parameter, and
+the corresponding chunk index [comma removed] to produce the next value to be
+assigned to the loop parameter. This repeats until the result of calling
+Has_Element on the loop parameter is False, or the associated parallel
+construct is left as a consequence of a transfer of control. In the absence
+of a transfer of control, the associated parallel construct of a parallel
+generalized iterator is complete when all of its logical threads of control
+are complete."
+
+****************************************************************
+
+Editor's response to the above: (January 7, 2021)
+
+First, changing "is" to "gets" (two places) does not seem to be an
+improvement. It's inconsistent with common usage (in particular, in paragraph
+13/5 of this same subclause) and seems informal to me as well. No change
+there.
+
+Second, changing "having" to "contains" (also two places) seems strange to me.
+Subprograms don't "contain" parameters, they just have them. OTOH, the wording
+"having" is weird as well, a different word might be better. But I haven't
+been able to find a better word, so in the absence of that, I'm not going to
+change this.
+
+Third, there does seem to be some unnecessary commas in here. Tucker admits
+that he overuses commas in his writing, so we agreed to give the text to Gary
+for tie-breaking. As of this writing, I haven't heard back from Gary, so I'll
+process this paragraph in the presentation changes so that we call see it and
+can discuss it again if needed.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, January 7, 2021 11:49 AM
+
+[Just the relevant parts of a private e-mail - Editor.]
+
+> > 10.2/5: This section reads strangely to me and many commas seem out
+> > of place (I could be wrong though). I have included the entire
+> > section here with suggested improvements surrounded by square
+> > brackets:
+> >
+> > "Upon return from Split_Into_Chunks, the actual number of chunks for
+> > the loop is determined by calling the Chunk_Count operation of the
+> > iterator, at which point one logical thread of control is initiated
+> > for each chunk [removed comma] with an associated chunk index in the
+> > range from one to the actual number of chunks.
+
+Without the comma this could be read as meaning "for each chunk that has
+an associated chunk index" (with => that has), which I don't think is
+intended. So to me the comma seems helpful.
+
+> Within each logical thread of control [removed
+> > comma] a loop parameter is created. If a chunk_specification with a
+
+Normally I think we would use a comma here, to mark off the subsidiary
+lead-in clause, but it maybe feels a bit heavy. Why not reverse the
+sentence parts:
+
+ A loop parameter is created within each logical thread of control.
+
+I think that reads better and needs no comma.
+
+> > discrete_subtype_definition is present in the associated parallel
+> > construct, then a chunk parameter is created [removed comma] and
+> > initialized with a value from the discrete subtype defined by the
+> > discrete_subtype_definition,
+
+I think this is OK without the comma, though I somewhat prefer the comma.
+Without the comma it could be read as "is created with a value and initialized
+with a value ...", and the comma avoids that potential reading, though it's
+probably clear enough what's meant and unlikely to be interpreted that way.
+
+> > so that the order of the chosen chunk parameter values correspond to
+> > the order of the chunk indices associated with the logical threads of control.
+> > The operation First of the iterator type [containing] a Chunk
+> > parameter [gets] called on the loop iterator, with Chunk initialized
+> > from the corresponding chunk index, to produce the initial value for
+> > the loop parameter. If the result of calling Has_Element on this
+> > initial value is False, then the execution of the logical thread of control is complete.
+> > Otherwise, the sequence_of_statements is conditionally executed and
+> > then
+
+I would add a comma before the "and then" above (normal rule in English for
+separating parts that can be read as sentences on their own).
+
+> > the
+> > Next operation of the iterator type [containing] a Chunk parameter
+> > [gets] called [comma removed] with the loop iterator, the current
+> > value of the
+
+I agree with removing the indicated comma.
+
+> > loop
+> > parameter, and the corresponding chunk index [comma removed] to
+> > produce the
+
+The comma may not be strictly needed I suppose, but to me it reads a little
+better with it. After the lengthy comma-separated conjunctions, to me it
+seems to parse more easily with the comma (a chance to catch one's breath...),
+but I don't feel super strongly about that. I could even see putting the long
+conjunction in parentheses:
+
+ ... called (with the ..., the ..., and the ...) to produce...
+
+but I won't suggest that. :)
+
+> > next value to be assigned to the loop parameter. This repeats until
+> > the result of calling Has_Element on the loop parameter is False, or
+> > the associated parallel construct is left as a consequence of a
+> > transfer of control. In the absence of a transfer of control, the
+> > associated parallel construct of a parallel generalized iterator is
+> > complete when all of its logical threads of control are complete."
+> >
+> > ============
+> >
+> > He doesn't really show the original wording here. He seems to be
+> > right that there are unnecessary commas in here (whether all of them
+> > are unnecessary is less clear -- but there sure are a lot of
+> > commas!). I'm less sure about the word changes, they are confusing
+> > to me. Let me put the changes he suggests for one of the sentences
+> > above into conventional ARG form:
+> >
+> > The operation First of the iterator type {containing}[having] a Chunk
+> > parameter {gets}[is] called on the loop iterator, with Chunk initialized
+> > from the corresponding chunk index, to produce the initial value for the
+> > loop parameter.
+> >
+> > I think the original form [in square brackets here] is better;
+> > that's especially true with "is called" as opposed to "gets called". "is called"
+> > is
+
+I agree that it should be "is called" rather that "gets called".
+
+> > also consistent with the existing Ada 2012 wording [para 13/5]
+> > (which is heavily modified, but not that part). I'm less annoyed by
+> > the other suggestion, although I don't think subprograms "contain"
+> > parameters as much as "having" parameters.
+
+Right. Maybe "that has" instead of "having"? (The first part of that sentence is
+still a bit awkward, as it could be read as saying that the iterator type rather
+than the operation has the parameter, but I don't have a good suggestion for
+avoiding that.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2021 12:01 PM
+
+[Another private e-mail - Editor.]
+
+...
+> Why not reverse the sentence parts:
+>
+> A loop parameter is created within each logical thread of control.
+>
+>I think that reads better and needs no comma.
+
+Perhaps, but I believe the "within each logical thread of control" is setting
+the stage for this whole paragraph, not just this one sentence, and so the
+topic of the paragraph may become less clear if you invert this introductory
+sentence.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2021 5:06 PM
+
+[Just the relevant parts of a private e-mail - Editor.]
+
+...
+
+> > > "Upon return from Split_Into_Chunks, the actual number of chunks
+> > > for the loop is determined by calling the Chunk_Count operation of
+> > > the iterator, at which point one logical thread of control is
+> > > initiated for each chunk [removed comma] with an associated chunk
+> > > index in the range from one to the actual number of chunks.
+>
+> Without the comma this could be read as meaning "for each chunk that
+> has an associated chunk index" (with => that has), which I don't think
+> is intended. So to me the comma seems helpful.
+
+??? That's exactly what I thought was intended. I don't see any difference
+between the statement with or without the comma, or for that matter, with
+your restatement (since every chunk has a chunk index; it doesn't make
+sense to have some chunks without chunk indexes). They all mean the same
+thing to me, so I think this is one of the most useless commas.
+
+Can you better explain the difference you are seeing (I realize that might
+be difficult)?
+
+...
+> > > discrete_subtype_definition is present in the associated parallel
+> > > construct, then a chunk parameter is created [removed comma] and
+> > > initialized with a value from the discrete subtype defined by the
+> > > discrete_subtype_definition,
+>
+> I think this is OK without the comma, though I somewhat prefer the
+> comma.
+> Without the comma it could be read as "is created with a value and
+> initialized with a value ...", and the comma avoids that potential
+> reading, though it's probably clear enough what's meant and unlikely
+> to be interpreted that way.
+
+I don't get this, either. The comma here seems completely unnecessary:
+"created and initialized" seems fine as whatever it is created with before it
+is initialized can't have a side-effect (it's of a discrete type). I vote for
+getting rid of comma. And I don't see where you are thinking readers are going
+to conjure up an extra "with a value".
+...
+...
+> > > also consistent with the existing Ada 2012 wording [para 13/5]
+> > > (which is heavily modified, but not that part). I'm less annoyed
+> > > by the other suggestion, although I don't think subprograms "contain"
+> > > parameters as much as "having" parameters.
+>
+> Right. Maybe "that has" instead of "having"? (The first part of that
+> sentence is still a bit awkward, as it could be read as saying that
+> the iterator type rather than the operation has the parameter, but I
+> don't have a good suggestion for avoiding that.)
+
+"that has" seems a little less informal, so I think that's a good suggestion.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, January 7, 2021 5:51 PM
+
+[Just the relevant parts of a private e-mail - Editor.]
+
+...
+> > > > "Upon return from Split_Into_Chunks, the actual number of chunks
+> > > > for the loop is determined by calling the Chunk_Count operation
+> > > > of the iterator, at which point one logical thread of control is
+> > > > initiated for each chunk [removed comma] with an associated
+> > > > chunk index in the range from one to the actual number of chunks.
+> >
+> > Without the comma this could be read as meaning "for each chunk that
+> > has an associated chunk index" (with => that has), which I don't
+> > think is intended. So to me the comma seems helpful.
+>
+> ??? That's exactly what I thought was intended. I don't see any
+> difference between the statement with or without the comma, or for
+> that matter, with your restatement (since every chunk has a chunk
+> index; it doesn't make sense to have some chunks without chunk
+> indexes). They all mean the same thing to me, so I think this is one of the
+> most useless commas.
+>
+> Can you better explain the difference you are seeing (I realize that
+> might be difficult)?
+
+I can try, but it's a bit subtle I admit, and maybe too subtle to matter.
+
+I agree that every chunk has a chunk index, but without the comma I can read
+that sentence as being something like (reversing parts of the sentence to make
+it clearer what I mean):
+
+ for each chunk that has an associated chunk index in the range from
+ one to the actual number of chunks, one logical thread of control
+ is initiated.
+
+It's unlikely anyone will interpret it that way, but that's sort of how it
+reads to me without the comma. For me the comma helps, and makes the sentence
+read more naturally, but evidently for you it doesn't.
+
+...
+> > > > discrete_subtype_definition is present in the associated
+> > > > parallel construct, then a chunk parameter is created [removed
+> > > > comma] and initialized with a value from the discrete subtype
+> > > > defined by the discrete_subtype_definition,
+> >
+> > I think this is OK without the comma, though I somewhat prefer the
+> > comma.
+> > Without the comma it could be read as "is created with a value and
+> > initialized with a value ...", and the comma avoids that potential
+> > reading, though it's probably clear enough what's meant and unlikely
+> > to be interpreted that way.
+>
+> I don't get this, either. The comma here seems completely unnecessary:
+> "created and initialized" seems fine as whatever it is created with
+> before it is initialized can't have a side-effect (it's of a discrete
+> type). I vote for getting rid of comma. And I don't see where you are
+> thinking readers are going to conjure up an extra "with a value".
+
+As I said, it's unlikely to be interpreted that way, and I'm fine with
+eliminating the comma.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2021 6:51 PM
+
+[Just the relevant parts of a private e-mail - Editor.]
+
+> ... This paragraph is gigantic anyway, so perhaps we should think about
+> breaking it up.
+...
+
+
+I would consider just splitting this into three paragraphs (yes I realize
+the first and last are single sentences):
+
+Upon return from Split_Into_Chunks, the actual number of chunks for the loop
+is determined by calling the Chunk_Count operation of the iterator, at which
+point one logical thread of control is initiated for each chunk, with an
+associated chunk index in the range from one to the actual number of chunks.
+
+Within each logical thread of control, a loop parameter is created. If a
+chunk_specification with a discrete_subtype_definition is present in the
+associated parallel construct, then a chunk parameter is created, and
+initialized with a value from the discrete subtype defined by the
+discrete_subtype_definition, so that the order of the chosen chunk parameter
+values correspond to the order of the chunk indices associated with the
+logical threads of control. The operation First of the iterator type having
+a Chunk parameter is called on the loop iterator, with Chunk initialized
+from the corresponding chunk index, to produce the initial value for the
+loop parameter. If the result of calling Has_Element on this initial value
+is False, then the execution of the logical thread of control is complete.
+Otherwise, the sequence_of_statements is conditionally executed and then the
+Next operation of the iterator type having a Chunk parameter is called, with
+the loop iterator, the current value of the loop parameter, and the
+corresponding chunk index, to produce the next value to be assigned to the
+loop parameter. This repeats until the result of calling Has_Element on the
+loop parameter is False, or the associated parallel construct is left as a
+consequence of a transfer of control.
+
+In the absence of a transfer of control, the associated parallel construct of
+a parallel generalized iterator is complete when all of its logical threads of
+control are complete.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent