Version 1.3 of ai12s/ai12-0418-1.txt
!standard 4.3.1(17.2/5) 21-01-12 AI12-0418-1/03
!standard 4.3.3(10)
!standard 4.3.5(76/5)
!standard 4.5.2(3.1/4)
!standard 5.5.2(10.2/5)
!standard 9.7.4(14/4)
!standard 12.3(11)
!standard 12.7(4.5/3)
!class binding interpretation 20-12-14
!status Amendment 1-2012 20-12-14
!status work item 20-12-14
!status received 20-12-14
!priority Low
!difficulty Easy
!qualifier Omission
!subject Presentation issues from Draft 26 review - part 3
!summary
Various wording issues were noted by reviewers of Draft 26.
!question
(1) 9.7.4(14/4) talks about "abort completion points", which is a forward
reference to 9.8. Typically, we have a cross-reference for forward references.
Should one be added here? (Yes.)
(2) 12.3(11) needs a comma in "In a generic unit Legality Rules ..."; the
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.)
(4) In 4.3.1(17.2/5), the parenthesized (box) is weird. Other similar rules
either do not include box at all (4.3.5(26/5), 12.7(4.5/3)) or include box
in the narrative text (4.3.4(11/5)), or even only use "box" but not <>
(12.6(10)). Should this be reworded? (Yes.)
(5) 12.7(4.5/3) ends with "must be given by <> as well". ISO does not allow
the use of the word "must" in normative text, and "as well" seems informal.
Should this be reworded? (Yes.)
(6) In 4.3.3(10), the wording of the "redundant" sentence is extremely
pedantic and hard to follow. Should this be reworded? (Yes.)
(7) The example 4.3.5(76/5) is pretty suboptimal as the conditional inside the
loop is not necessary. Should a simpler form be used? (Yes.)
(8) In 4.5.2(3.1/4), "for" should be "of" for consistency, since the following
sentence uses "of" instead of "for". Change this? (Yes.)
!recommendation
(1) Add (see 9.8) after "abort completion points".
(2) Add the comma.
(3) Add one comma, remove two others, replace "having" with "that has" (2
places), and split into three parts.
(4) Move box in front of "compound delimiter".
[=== Editor's question: Argubly, 4.3.5(26/5) should be reworded to
include "box" somewhere, so that at least all of the rules in the
aggregate clauses are consistent. Or possibly make all three of
4.3.1(17.2/5), 4.3.4(11/5), and 4.3.5(26/5) use consistent wording
-- these are all new Ada 202x rules. As that seemed to be a lot of churn,
and the wording to chose is not obvious, I've left that decision open.===]
(5) Replace "must" with "shall also", and delete "as well".
(6) Remove the phrase "where an array_aggregate is permitted" and replace
"the aggregate" with "an array_aggregate".
(7) Replace the single loop with two loops, which is closer to the actual
expansion.
(8) Replace "for" with "of".
!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 4.3.1(17.2/5):
* use the {box} compound delimiter <> rather than an expression;
Modify 4.3.3(10):
An others choice is allowed for an array_aggregate only if an applicable index
constraint applies to the array_aggregate. An applicable index constraint is a
constraint provided by certain contexts[ where an array_aggregate is permitted]
that can be used to determine the bounds of the array value specified by [the
aggregate]{an array_aggregate}. Each of the following contexts (and none
other) defines an applicable index constraint:
Replace 4.3.5(76/5):
-- Is equivalent (assuming set semantics) to:
S := Empty_Set;
for Item in -5 .. 5 loop
if Item /= 0 then
Include (S, Item);
end if;
end loop;
with:
-- Is equivalent (assuming set semantics) to:
S := Empty_Set;
for Item in 1 .. 5 loop
Include (S, Item)
end loop;
for Item in -5 .. -1 loop
Include (S, Item)
end loop;
Modify 4.5.2(3.1/4):
If the tested type is tagged, then the tested_simple_expression shall
resolve to be of a type that is convertible (see 4.6) to the tested
type; if untagged, the expected type {of}[for] the tested_simple_expression is
the tested type. The expected type of a choice_simple_expression in a
membership_choice, and of a simple_expression of a range
in a membership_choice, is the tested type of the membership operation.
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
{(see 9.8) }within the execution of the abortable_part.
Modify 12.3(11):
In a generic unit{,} Legality Rules are enforced at compile time of the
generic_declaration and generic body, given the properties of the formals.
In the visible part and formal part of an instance, Legality Rules are
enforced at compile time of the generic_instantiation, given the properties
of the actuals. In other parts of an instance, Legality Rules are not
enforced; this rule does not apply when a given rule explicitly specifies
otherwise.
Modify 12.7(4.5/3):
f a formal_package_association for a formal type T of the template is given
by <>, then the formal_package_association for any other
generic_formal_parameter_declaration of the template that mentions T directly
or indirectly {shall also}[must] be given by <>[ as well].
!discussion
(See !recommendation.)
!corrigendum 4.3.1(17.1/2)
Insert after the paragraph:
A record_component_association for a discriminant without a
default_expression shall have an expression rather than <>.
the new paragraphs:
A record_component_association of the record_component_association_list
of a record_delta_aggregate shall not:
- use the box compound delimiter <> rather than an expression;
- have an expression of a limited type;
- omit the component_choice_list; or
- have a component_choice_list that is an others choice.
For a record_delta_aggregate, no two component_selector_names
shall denote components declared within different variants of the same
variant_part.
!corrigendum 4.3.3(10)
Replace the paragraph:
An others choice is allowed for an array_aggregate only if an
applicable index constraint applies to the array_aggregate. An
applicable index constraint is a constraint provided by certain contexts
where an @array_aggregate> is permitted that can be used to determine the
bounds of the array value specified by the aggregate. Each of the following
contexts (and none other) defines an applicable index constraint:
by:
An others choice is allowed for an array_aggregate only if an
applicable index constraint applies to the array_aggregate. An
applicable index constraint is a constraint provided by certain contexts
that can be used to determine the bounds of the array value specified by an
array_aggregate. Each of the following contexts (and none other) defines
an applicable index constraint:
!corrigendum 4.3.5(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 4.5.2(3.1/4)
Replace the paragraph:
If the tested type is tagged, then the tested_simple_expression shall
resolve to be of a type that is convertible (see 4.6) to the tested
type; if untagged, the expected type for the tested_simple_expression is
the tested type. The expected type of a choice_simple_expression in a
membership_choice, and of a simple_expression of a range
in a membership_choice, is the tested type of the membership operation.
by:
If the tested type is tagged, then the tested_simple_expression shall
resolve to be of a type that is convertible (see 4.6) to the tested
type; if untagged, the expected type of the tested_simple_expression is
the tested type. The expected type of a choice_simple_expression in a
membership_choice, and of a simple_expression of a range
in a membership_choice, is the tested type of the membership operation.
!corrigendum 5.5.2(10/3)
Replace the paragraph:
For a generalized iterator, the loop parameter is created, the
iterator_name is evaluated, and the denoted iterator object becomes
the 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
loop_statement is complete. Otherwise, the 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.
by:
*** The replacement text is found in the conflict file ***
!corrigendum 9.7.4(14/4)
Replace the paragraph:
Note that these examples presume that there are abort completion points within
the execution of the abortable_part.
by:
Note that these examples presume that there are abort completion points
(see 9.8) within the execution of the abortable_part.
!corrigendum 12.3(11)
Replace the paragraph:
In a generic unit Legality Rules are enforced at compile time of the
generic_declaration and generic body, given the properties of the formals.
In the visible part and formal part of an instance, Legality Rules are
enforced at compile time of the generic_instantiation, given the
properties of the actuals. In other parts of an instance, Legality Rules
are not enforced; this rule does not apply when a given rule explicitly
specifies otherwise.
by:
In a generic unit, Legality Rules are enforced at compile time of the
generic_declaration and generic body, given the properties of the formals.
In the visible part and formal part of an instance, Legality Rules are
enforced at compile time of the generic_instantiation, given the
properties of the actuals. In other parts of an instance, Legality Rules
are not enforced; this rule does not apply when a given rule explicitly
specifies otherwise.
!corrigendum 12.7(4.5/3)
Replace the paragraph:
- If a formal_package_association for a formal type T of the
template is given by <>, then the formal_package_association for any
other generic_formal_parameter_declaration of the template that mentions
T directly or indirectly must be given by <> as well.
by:
- If a formal_package_association for a formal type T of the
template is given by <>, then the formal_package_association for any
other generic_formal_parameter_declaration of the template that mentions
T directly or indirectly shall also be given by <>.
!ASIS
No ASIS effect.
!ACATS test
No ACATS tests should be needed, none of these changes change any semantics.
!appendix
From the AARM review of John Barnes, September 2020
9.7.4(14/4) I would add (see 9.8) but not essential. It is a forward
reference.
12.3(11) Please put a comma thus "In a generic unit, Legality Rules…"
****************************************************************
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.
****************************************************************
From the AARM review of Richard Wai, October 2020
4.3.1(17.3/5):
The parenthesized "box" seems unnecessary. In other places, the text simply
says "<>".
"use the compound delimiter <> [(box)] rather than an expression;"
For an precedent in existing text, see 4.3.3-49.i/3, and new
wording 49.k/4 & 4.3.5-26/5
[Editor's response:
AARM notes don't provide precedent for normative rules, so the only
4.3.5(26/5) provides any precedent. Looking for other similar rules:
* A similar Legality Rule is 4.3.4(11/5), and that uses "shall not use the
box symbol <>".
* 12.6(10) just uses "specified by a box" without using <> at all.
* 12.7(4.5/3) uses "given by <>" without mentioning box at all.
So it appears this is an evolving usage without much consistency. Moreover,
for explanatory text like this, we try to give it exactly once per subclause,
so precedent isn't necessarily obvious -- the equivalence of <> and "box"
could be mentioned earlier in the clause.
So I think making the text more like 4.3.4(11/5) would be better, not everyone
knows that <> is called box and it doesn't hurt to reiterate it. So perhaps:
"use the box compound delimiter <> rather than an expression;"
end Editor's response.]
-----
4.3.3(10)
Wording of the "redundant" sentence is extremely pedantic and
hard to follow.
Suggestion: "An applicable index constraint is a constraint
that can be determined from the context of the aggregate,
such as a subtype constraint or target array bounds"
Or something like that..
[Editor's response:
These sorts of sentences cannot be too sloppy, since they formally *are*
normative wording (the "redundant" brackets are *not* normative, and since the
sentence is given in a normative paragraph). I'm dubious about giving examples
in this sentence given that the formal definition is directly below.
The "where an array_aggregate is permitted part" seems useless and probably is
what is confusing you. An array_aggregate is permitted almost everywhere! It's
the others choice that isn't allowed in some contexts. And we're talking about
array_aggregates; who cares about contexts where they're not allowed! The
first sentence already mentioned that others choices aren't permitted in some
contexts, so we don't need to repeat it. So I suggest dropping the "permitted"
part, giving:
An applicable index constraint is a constraint provided by certain contexts
that can be used to determine the bounds of the array value specified by an
array_aggregate.
Since this is original Ada 95 wording, it'll go into the presentation AI.
end Editor's response.]
-----
4.3.5(76/5)
The example is pretty suboptimal. The conditional inside the
loop is not necessary.
for Item in 1 .. 5 loop
Include (S, Item)
Include (S, -Item)
end loop;
This also more closely reflects what will actually happen,
and is easier to understand.
[Editor's response:
I'd probably write this with two loops to reflect what the aggregate actually
expands into:
for Item in 1 .. 5 loop
Include (S, Item)
end loop;
for Item in 1 .. 5 loop
Include (S, -Item)
end loop;
With this expansion, we don't need the "assuming set semantics", either, as
this is what is generated.
But I'm not certain whether this really reflects the point that was intended
by the author. The previous example already shows the basic expansion. I'm
guessing that the intent here was to show that the set would be [-5, -4, -3,
-2, -1, 1, 2, 3, 4, 5], but since one can't use aggregate notation to explain
how aggregate notation is interpreted (!), he ended up with this. Perhaps it
would be better to write:
for Item in 1 .. 5 loop
Include (S, Item)
end loop;
for Item in -5 .. -1 loop
Include (S, Item)
end loop;
This isn't quite as close to the expansion, but more obviously shows the
result than either of the other suggestions.
end Editor's response.]
****************************************************************
Questions? Ask the ACAA Technical Agent