Version 1.5 of ai12s/ai12-0418-1.txt

• 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.

Pre'Class

This aspect specifies a class-wide precondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide precondition expression. If not specified for an entity, then if no other class-wide precondition applies to the entity, the class-wide precondition expression for the entity is the enumeration literal True.

Pre'Class

This aspect specifies a class-wide precondition for a dispatching operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide precondition expression. If not specified for an entity, then if no other class-wide precondition applies to the entity, the class-wide precondition expression for the entity is the enumeration literal True.

Post'Class

This aspect specifies a class-wide postcondition for an operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide postcondition expression. If not specified for an entity, the class-wide postcondition expression for the entity is the enumeration literal True.

Post'Class

This aspect specifies a class-wide postcondition for a dispatching operation of a tagged type and its descendants; it shall be specified by an expression, called a class-wide postcondition expression. If not specified for an entity, the class-wide postcondition expression for the entity is the enumeration literal True.

• 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.

• 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 <>.

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.]

****************************************************************

From the AARM review of Steve Baird, October 2020

   6.1.1 Paragraph 1 seems to suggest that Pre'Class and Post'Class
   aspects may be specified for an access-to-subprogram type. This is
   contradicted later. We prefer it if the RM doesn't contradict
   itself, although the meta-rule "if two rules in the RM contradict
   each other and one is more specific than the other, then the
   more specific rule takes precedence" does seem to apply here.
   Is there a problem here that needs fixing?

[Editor's response: The only fix would be to delete the class-wide aspects
from their current locations, move them after the current ones, and give them
a new more restrictive header. Seems painful, and we don't repeat the restriction
to primitives of a tagged type for the class-wide aspects, either. That is,
it was always expected that the class-wide aspects would not allow everything
supported by the other versions. So this seems like something that should have
been done initially if it was going to be done at all.

Tucker suggests replacing "an operation" with "a dispatching operation" for
for Pre'Class and Post'Class. This doesn't fix the concern directly, but is
thought to be an improvement.
end Editor's response.]

   In 6.1.1(7/5), do we need to add the one word "anonymous" to clarify that
   the rule
       Similarly, a name that denotes a formal access parameter
       (or S'Result) of type access-to-T is interpreted as having type
       access-to-NT.
   does not apply in the case of a named access-to-T function result type?

[Editor's response: I think it would be better to refer to an "access result"
here to mirror the use of "access parameter", but certainly a fix is needed.
So I used:
       Similarly, a name that denotes a formal access parameter
       (or S'Result{ of an access result}) of type access-to-T is interpreted
       as having type access-to-NT.
end Editor's response.]

   6.1.1(8/3) reads
      For an attribute_reference with attribute_designator Old, if the
      attribute reference has an expected type or shall resolve to a given
      type, the same applies to the prefix; otherwise, the prefix shall be
      resolved independently of context.

   Perhaps there is no problem here, but I'm wondering whether
   "shall resolve to a given type" ought to be "shall resolve to a
   given type or class of types" or something similar.

[Editor's response: We never talk about "shall resolve to a
class of types. The conditional expression wording does talk about "expected
type in a class of types". It seems rare that we do that, but there is some
precedent.

Tucker suggested "expected type {or class of types} or shall resolve to"
to fix the problem. That has an "or" problem, so I enclosed the insertion in
parens:

"expected type {(or class of types)} or shall resolve to"
end Editor's response.]

6.5

   In 5.1/5, add an "if any" modifier (surrounded by commas or parens?).
     The expression of an extended_return_statement is the expression
     (if any)
     of the extended_return_object_declaration of the extended_return_statement.

   ---

   In 8/4 (in the context of a return statement), we talk about
     "the expression".
   Should this be "the expression of the return statement"? I know,
   what other expression could it be? But still ...
   It doesn't help any that the possibility exists that there is no
   such expression and this possibility isn't addressed until after
   the reference to "the expression", when we get to the
   "unless the return object is defined by" part.

   This is hardly an oversight; this point was discussed (see TBH note
   8.d.1/4), so perhaps nothing more needs to be done here.
   I think the TBH note is an acknowledgement that there is a problem
   and that the proposed two-word addition would help with that problem.

[Editor's response: The correct definition of the term "expression of a return
statement" wasn't made until now (Ada 202x, by AI12-0173-1), while the wording 
you are referring to was trying to avoid the badly defined term in Ada 2012. 
Probably the fix you suggest should be added and the TBH deleted. Part of the 
TBH should go after 5.1/5 as a ramification to define "expression of a return 
statement", which is used a lot but never formally defined. The "(if any)"
suggestion seems like a good one. (I don't want to formally define
"expression of a return statement", that's more likely to cause trouble than 
fix anything.) This is included in AI12-0418-1.]

   In 6.5.1(1/5), the nonnormative text "it may propagate an exception or
   loop forever" might be interpreted as an exhaustive list
   (suggesting, for example, that blocking forever awaiting the acceptance
   of an entry call is not a possibility).

   Perhaps "it may, for example, propagate ...".

****************************************************************