Version 1.7 of ai12s/ai12-0427-1.txt

• an expression, which is either evaluated to produce a single value, or which (as in a precondition) is to be evaluated at particular points during later execution; or

• an expression (other than an aggregate), which is either evaluated to produce a single value, or which (as in a precondition) is to be evaluated at particular points during later execution;

• an identifier specific to the aspect.

• an identifier specific to the aspect; or

• an aggregate, which is positional or named, and is composed of elements of any of these four kinds of constructs.

• An Ada enumeration type corresponds to a C enumeration type with corresponding enumeration literals having the same internal codes, provided the internal codes fall within the range of the C int type. The Ada Boolean type corresponds to the C bool type.

• An Ada enumeration type corresponds to a C enumeration type with corresponding enumeration literals having the same internal codes, provided the internal codes fall within the range of the C int type.

From: Tucker Taft
Sent: Thursday, March 18, 2021  11:07 AM

Here is a comment that might best be considered as a "WG9-stage" comment 
on the latest draft (#29.3) of the Ada 202X RM: [It was WG 9 issue #8, see
below - Editor.]

In RM 13.1.1(19/3-22/3) we have:

Depending on which aspect is identified by the aspect_mark, an 
aspect_definition specifies:
* a name that denotes a subprogram, object, or other kind of entity;
* an expression, which is either evaluated to produce a single value, or 
  which (as in a precondition) is to be evaluated at particular points 
  during later execution; or
* an identifier specific to the aspect.

This is relatively old wording, and doesn't mention "aggregate" which is of 
course a kind of expression, but in newer wording is called out separately, 
and it is certainly misleading to talk about it being evaluated to produce 
a "single value."

I would suggest we augment the above as follows:

Depending on which aspect is identified by the aspect_mark, an 
aspect_definition specifies:
* a name that denotes a subprogram, object, or other kind of entity;
* an expression{ (other than an aggregate)}, which is either evaluated to 
  produce a single value, or which (as in a precondition) is to be evaluated 
  at particular points during later execution;[ or]
* an identifier specific to the aspect{; or
* an aggregate, which is positional or named, and is composed of elements of 
  any of these four kinds of constructs}.

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

From: Randy Brukardt
Sent: Saturday, March 20, 2021  2:20 AM

I agree this should be fixed as you suggest. It looks like an oversight to me; 
we made a similar fix to 13.1.1(5 through 11) and I'd guess we missed that 
there was a second place that needed a fix.

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

From: Tucker Taft
Sent: Thursday, March 18, 2021  11:31 AM

Randy suggested I bring this comment to the ARG as a WG9-stage comment.


We have added C_bool to Interfaces.C, which is defined to be equivalent to C's
"bool" (or  "_Bool").  It now seems misleading to say that Ada's 
Standard.Boolean type "corresponds" to the C bool type.  The point of 
introducing C_bool was so that you could be certain that you had a type 
compatible with C, and there was no guarantee that, for example, a record 
component of type Standard.Boolean would match a C struct component of type 
"bool."

The current state of RM B.3(65.1/5) is

* An Ada enumeration type corresponds to a C enumeration type with 
  corresponding enumeration literals having the same internal codes,
  provided the internal codes fall within the range of the C int type.
  The Ada Boolean type corresponds to the C bool type.

That last sentence was not present when this paragraph was added, which 
originated from AI12-0135-1.  The last sentence came from AI12-0411-1, which
defined Interfaces.C.C_bool.  I admit I wrote the original version of 
AI12-041101, but now that last sentence seems to miss the whole point of the
addition of C_bool, namely, that there is no requirement that the Ada Boolean
type itself corresponds to the C bool type.  It would make more sense to say 
something like the following, I believe:

* An Ada enumeration type corresponds to a C enumeration type with 
  corresponding enumeration literals having the same internal codes, 
  provided the internal codes fall within the range of the C int type.
  Interfaces.C.C_bool, a boolean type derived from the Standard.Boolean 
  type, corresponds to the C bool type.

We could also mark this new last sentence as "redundant" (i.e., inside [ ... ] 
in the AARM) as it is implied by other wording now in the draft RM that says 
that C_bool corresponds to C's bool, plus the declaration of C_bool to be 
derived from Standard.Boolean.

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

From: Jean-Pierre Rosen
Sent: Thursday, March 18, 2021  11:43 AM

>     * An Ada enumeration type corresponds to a C enumeration type with
>     corresponding enumeration literals having the same internal codes,
>     provided the internal codes fall within the range of the C int type.
>     Interfaces.C.C_bool, a boolean type derived from the
>     Standard.Boolean type, corresponds to the C bool type.
> 
Does it correspond to this sea bull?
https://www.alamy.com/stock-photo-greenland-sea-norway-svalbard-archipelago-spitsbergen-walrus-odobenus-55591858.html

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

From: Tucker Taft
Sent: Thursday, March 18, 2021  12:15 PM

Of course the Sea Bull Walrus would let us know that...

   The time has come,' the Walrus said,
      To talk of many things:
   Of shoes — and ships — and sealing-wax —
      Of cabbages — and kings —
   And why the sea is boiling hot —
      And whether pigs have wings.'
   And whether bool is C_Bool,
      Or Standard dot Booling!

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

From: Randy Brukardt
Sent: Saturday, March 20, 2021  2:18 AM

... 
> I admit I wrote the original version of AI12-041101, but now that last 
> sentence seems to miss the whole point of the addition of C_bool, 
> namely, that there is no requirement that the Ada Boolean type itself 
> corresponds to the C bool type.

I certainly agree with this, but I thought that we had that discussion at the 
time and I lost (and the sentence remained). I certainly thought the intent 
was as written -- this is Implementation Advice anyway, no one has to follow
it.

>It would make more sense to say something like the following, I believe:

>* An Ada enumeration type corresponds to a C enumeration type with
>  corresponding enumeration literals having the same internal codes,  
>  provided the internal codes fall within the range of the C int type.
>  Interfaces.C.C_bool, a boolean type derived from the Standard.Boolean  
>  type, corresponds to the C bool type.

I don't see any reason to mention Interfaces.C.C_bool here. We don't mention 
any of the other Interfaces.C types in this Implementation Advice, because 
they are already *normatively* corresponding (in B.3(43/5)). It makes no sense
to repeat that in IA - IA is weaker, after all.

>We could also mark this new last sentence as "redundant" (i.e., inside 
>[ ... ] in the AARM) as it is implied by other wording now in the draft  
>RM that says that C_bool corresponds to C's bool, plus the declaration  
>of C_bool to be derived from Standard.Boolean.

I see no reason to mention it at all, as stated above. I thought people wanted 
to encourage a correspondence between Boolean and the C bool type, otherwise 
it should never have been there in the first place.

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

From: Tucker Taft
Sent: Saturday, March 20, 2021  5:21 PM

I am happy to drop the problematic sentence completely.  I had the sense that 
Randy or someone else thought the sentence should be preserved, but if so, it 
should not imply a direct correspondence between Ada Boolean and C bool, but 
rather indicate the C_bool type, derived from Boolean, is required to 
correspond.  But that is definitely redundant with the update made to 
B.3(43/5), so happy to leave it out completely.

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

From the WG 9 review, issue #2.

Stream attributes define the subtype of the parameter of the associated
subprograms with 13.13.2(51/3). We don't have any similar rule for Put_Image
in 4.10. The definition of Put_Image seems to suggest that the parameter is
of type T, but types do not have names in Ada -- one always has to specify a
subtype.

Tucker also notes that we don't mention that the implicit calls of Put_Image
propagate any exceptions (including those caused by a subtype check
failure); we doubt anyone would expect anything else, but it usually is
explicitly mentioned in the RM.

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

From the WG 9 review, issue #151.

8.5(5): This note says that an object of an anonymous access type cannot be 
renamed. However, it seems to me that the second alternative in RM 8.5.1 (1/5),
the "access_definition" case, does allow such a renaming. Similarly, RM 8.5 (5)
says that a single task or protected object cannot be renamed since the 
corresponding type is anonymous, but as we can now omit the subtype_mark from
the object_renaming_declaration, it seems that such entities can be renamed. 
Either I am wrong, or the statements in RM 8.5 (5) are wrong.

Tucker Taft replied:

Another good catch! I would suggest we change the note to say:

    10 A task or protected object that is declared by an explicit 
    object_declaration can be renamed as an object. However, a single task
    or protected object [cannot]{can} be renamed {only using the form of 
    renaming that omits specifying the subtype} [since the corresponding type
    is anonymous (meaning it has no nameable subtypes). For similar reasons, 
    an object of an anonymous array or access type cannot be renamed].

This is a bit informal (i.e. "specifying the subtype" is not a defined 
technical notion) but that is generally fine for a "Note".

Your editor replied:

I wonder if this note retains enough value to bother with it at all. The 
original purpose was to say that not all objects can be renamed, but that is
False with Ada 202x, and indeed one now can rename most values as well. Saying
that something can only be renamed with the most simple (and likely common) 
form of renaming is hardly interesting. We don't need notes to tell people 
random facts about the language.

I'll write up deleting the note in AI12-0427-1 (the fixup AI), and we can 
decide if that is acceptable or not in the ARG.

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

From the WG 9 review, issue #152.

The nominal (sub)type specified in 8.6(17.1/5) for the "current instance"
value seems to be overridden in RM 7.3.2 (5/4) for the aspect
Type_Invariant'Class, and in RM 7.3.3 (4/5) for the aspect 
Default_Initial_Condition, where different types ("NT") are specified for 
the current instance. Perhaps this apparent contradiction should be addressed
in some way, by a note or by an exception phrase in the general rule.

Tucker Taft replied:

Might want to add simply "Unless otherwise specified in this document, ...".

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

From the WG 9 review, issue #8.

In RM 13.1.1(19/3-22/3) we have:

Depending on which aspect is identified by the aspect_mark, an
aspect_definition specifies:

  * a name that denotes a subprogram, object, or other kind of entity;
  * an expression, which is either evaluated to produce a single value, or
    which (as in a precondition) is to be evaluated at particular points during
    later execution; or
  * an identifier specific to the aspect.

This is relatively old wording, and doesn't mention "aggregate" which is of
course a kind of expression, but in newer wording is called out separately,
and it is certainly misleading to talk about it being evaluated to produce a
"single value."

Suggested fix:

We should augment the above as follows:

Depending on which aspect is identified by the aspect_mark, an
aspect_definition specifies:

  * a name that denotes a subprogram, object, or other kind of entity;
  * an expression{ (other than an aggregate)}, which is either evaluated to
    produce a single value, or which (as in a precondition) is to be evaluated
    at particular points during later execution;[ or]
  * an identifier specific to the aspect{; or
  * an aggregate, which is positional or named, and is composed of elements of
    any of these four kinds of constructs}.

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

From the WG 9 review, issue #3.

The listed paragraphs give requirements on subprograms specified for
attributes (aspects) via an attribute_definition_clause. There is no rule
that does that for aspects specified via aspect_specifications.

There is a usual equivalence of aspects that can be specified via
aspect_specifications, and the Dewar rule applies here -- it would be highly
unusual for these rules to act differently than many others.

However, we have been trying to eliminate semantic rules that specifically
mention how some aspect/attribute is specified, since those can be misread
easily and are always confusing. So we believe these paragraphs should be
rewritten.

Note that if we do that for 13.3(6), it should be moved somewhere more
general (probably 13.1) as it currently is part of rules that only apply to
attribute_definition_clauses. (A reason this change should be made, IMHO -
RLB) Even language lawyers (for example, Steve Baird) have had difficulty
locating this rule when wondering what rules apply to a particular aspect.

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

From the WG 9 review, issue #4.

3.5(56.4/3) says:

If a derived type with no primitive subprograms inherits a boolean
Default_Value aspect, the aspect may be specified to have any value for the
derived type.

Tucker tells me that the "with no primitive subprograms" was included to
ensure that we didn't override 13.1(10) with this rule. However, Ada 202x
removes the bulk of 13.1(10) (which mostly was intended to avoid expensive
implicit conversions -- but the effect was to prevent programmers from
writing derived types that they needed even if the expensive conversion was
not a problem). This means this rule as written is a wart, as it seems to
prevent non-confirming Default_Value aspects in the case of a type with
primitive subprograms.

3.6(22.2/3) has similar wording.

Suggested fix: drop the words "with no primitive subprograms" from both of
these rules.

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

From the WG 9 review, issue #9.

[This is just a repeat of the ARG thread saved above, starting with a
message from Tucker Taft, Thursday, March 18, 2021  11:31 AM - Editor.]

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

From the WG 9 review, issue #16.

In 4.5.10 (34/5) we have
"For a parallel reduction expression, it is a bounded error if the reducer 
subprogram is not associative. That is, for any arbitrary values of subtype 
Value_Type A, B, C and a reducer function R, the result of R (A, R(B, C)) 
should produce a result equal to R (R (A, B), C)). The possible consequences
are Program_Error, or a result that does not match the equivalent sequential
reduction expression due to the order of calls on the reducer subprogram 
being unspecified in the overall reduction. Analogous rules apply in the 
case of a reduction procedure."

The second sentence is misleading in that it is explaining what associative 
means while the first sentence talks about being not associative. Maybe 
better: "For any arbitrary values of subtype Value_Type A, B, C, an 
associative reducer function R should guarantee that the result 
of R (A, R(B, C)) is equal to R (R (A, B), C))."

In addition, it could be mentioned that addition and multiplication of 
floating point numbers are prominent examples of not associative operations. 
A fact that many programmers are not aware of.

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

Editor's reply to the previous item:

We had a very hard time agreeing on wording for this one, so I would want to 
change it as little as possible. As such, I suggest adding "; it is a bounded
error if R does not" to the end of the second sentence to provide the 
clarification you are asking for, This was added to the fixups AI 
(AI12-0427-1).

As far as the second suggestion is concerned, we don't want "fun facts" in the 
normative rules of the Standard. I suppose it could be mentioned in the AARM 
or a user note, but that seems to be of less value since it would be separated
from the reason it matters. So I'm not going to do anything with this second 
point.

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

From the WG 9 review, issue #114.

We have relaxed the rules relating to specifying type-related representation 
aspects when there are primitives that might be inherited by derived types 
with a different representation. However, we did not take into account that 
some parameters are necessarily passed by reference, even if the type itself
is not a by-reference type. Such parameters cannot easily be converted 
automatically when calling an inherited subprogram. One option is for such 
"by-reference primitives" to "become" abstract when inherited by a derived 
type with some different representation aspect. However, that is incompatible
with generics, since currently all operations are available on a formal
derived type inside a generic, even though all operations are effectively 
inherited. After discussion, the simplest solution seems to be to go back to 
disallowing the specification of a nonconfirming representation aspect if 
there are any "by-reference primitives." Hence, I would suggest we modify 
13.1(10/5) as follows:

Modify RM 13.1(10/5):

    {A by-reference primitive is a user-defined primitive subprogram for a 
    type T that has an access result designating type T, or that has a formal
    parameter that is an access parameter designating type T or is aliased and
    of type T.} It is illegal to specify a nonconfirming type-related 
    representation aspect for an untagged [by-reference] type T if it is
    derived from a by-reference type {or inherits one or more by-reference
    primitives}, or if one or more types have been derived from T prior to 
    the specification of the aspect {and type T is a by-reference type or 
    defines one or more by-reference primitives that are inherited by these 
    descendants}.

    {AARM Reason: Access parameters, access results, and aliased parameters 
    cannot be converted as part of invoking an inherited subprogram if the 
    representation of the designated types might be different.}

We could simplify this further, which would effectively relax the existing 
rules for a by-reference type that has no primitives, to the following:

    {A by-reference primitive is a user-defined primitive subprogram for a 
    type T, if T is a by-reference type, or if the primitive has an access 
    result designating type T, or has a formal parameter that is an access 
    parameter designating type T or is aliased and of type T.} It is illegal
    to specify a nonconfirming type-related representation aspect for an 
    untagged [by-reference] type T if it [is derived from a by-reference 
    type] {inherits one or more by-reference primitives}, or if one or more
    types have been derived from T prior to the specification of the aspect
    {and type T defines one or more by-reference primitives that are 
    inherited by these descendants}.

In the spirit of removing unnecessary restrictions, this simpler rule might be 
preferred.

[Later message]

Randy noted that we should probably not change the rules on by-reference 
types, since in 4.6(58.2/4) we assume all by-reference types can be converted
without representation change. So that implies we should retain the 
distinction as suggested in the first alternative proposed above.

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

From the WG 9 review, issue #5.

[From Randy Brukardt:]

Paragraphs 6.4.1(5.1/5) through 6.4.1(5.4/4) define a Legality check for
some scalar view conversions passed to OUT mode parameters.

When a type is derived, any inherited subprograms are called with the actual
parameters of the new type view converted to the parent type. This can cause
an anomaly, in that an explicit call would be illegal while calling an
inherited routine (which makes the same call implicitly) is legal.

Tucker notes that 6.4.1(15.1/5) says that this view conversion raises
Program_Error. Therefore, there is no language bug in that code that does
not follow the principles cannot be executed. OTOH, the rule Tucker refers
to was only intended to be used in generic bodies (and there is an AARM note
to that effect). So implementers and users alike are likely to be confused.

Moreover, we have a Language Design Principle (admittedly, not always
followed) that a construct which will always raise an exception should be
detected at compile-time. So it seems that a Legality Rule is missing here.

Suggested fix: Add a Legality Rule to reject any call on an inherited
routine with an out parameter where the implied view conversion would be
illegal.

Example: Here is an example of this situation:

package P1 is
   type Moddy is mod 2**16;

   procedure Convert (Ival : in Integer; Mval : out Moddy);

end P1;

with P1;
package P2 is
   type IModdy is new P1.Moddy
      with Default_Value => 65535; -- [A]
   -- Convert inherited here.
end P2;

with P1, P2;
procedure Tester is
   V : P2.IModdy;
begin
   P1.Convert (10, P1.Moddy(V)); -- [B]
   P2.Convert (10, V); -- [C]
end Tester;

[C] is implemented as [B] -- 3.4(27/2).

But [B] is illegal by 6.4.1(5.1-4/5) -- the operand type has a Default_Value
and the target type does not.

The equivalence is only for Dynamic Semantics, so the Legality Rule does not
apply. But 6.4.1(15.1/5) does apply, so [C] is required to raise Program_Error.

[From Tucker Taft:]

It would perhaps be better to require such primitives to be overridden, since 
having a primitive that is illegal to call might have cascading weird effects.
On the other hand, this only comes up with non-tagged types, so there is no 
dispatching to worry about, and ancestor primitives re-emerge in a generic, so
perhaps I am merely sowing Fear, Uncertainty, and Doubt.

It still seems friendlier, though, to require overriding. You could of course 
override with a subprogram that always raised Program_Error if so desired, but
at least you are being explicit about it.

[From Randy Brukardt:]

I didn't suggest requiring overriding, as that is something that currently 
happens only for tagged types. As such, adding it for an unlikely case for 
untagged types could be a substantial implementation burden. (If tagged 
derivation is separately implemented from untagged derivation, then one would 
need to implement a new mechanism for untagged types.) I do agree it would be 
friendlier to a user, but only in unusual circumstances (and it would be 
incompatible with Ada 2012 in those circumstances).

I don't think there would be any "cascading weird effects", as you note that 
there isn't any effect in generics.

[From Tucker Taft:]

An alternative would be to add yet another restriction on applying a 
representation clause to a type with primitives. It used to be completely
illegal, and now we are beginning to find out why... ;-) But at least we are
certain we are keeping all of the "hair" in the same place, namely, in 
limiting how far we loosen this rule. I'll see if I can come up with wording 
for the two different approaches -- disallowing the call, or disallowing the 
representation change -- and I'll add it as another comment.

[From Randy Brukardt:]

It would seem weird to add something to 13.1(10/5) about a specific aspect 
used with a specific kind of parameter - it doesn't seem general enough. But
I suppose we could have a wart rule in 3.5 specifically to disallow such 
Default_Values. That seems less friendly than just disallowing uses of such
inherited routines, but it's probably not a huge issue either way.

[From Steve Baird:]

Given our recent discussion about inherited subprograms with
aliased untagged parameters, it sounds like we are already planning
on adding new cases to 13.1(10) for other reasons. So I would prefer
to address this problem there.

[From Tucker Taft:]

We are simplifying the current rule in 3.5, so perhaps we could make it more 
complex again:

    If a derived type [with no primitive subprograms] inherits a boolean 
    Default_Value aspect, the aspect may be specified to have any value for 
    the derived type. {If a derived type T does not inherit a Default_Value 
    aspect, it shall not specify such an aspect if it inherits a primitive 
    subprogram that has a parameter of type T of mode OUT.

    AARM Reason: This is to avoid violating the rules specified in 6.4.1 about 
    view conversions of OUT parameters with a specified Default_Value aspect.}

The rules in 6.4.1(5.1/5) through 6.4.1(5.4/4) only disallow cases where one 
type has the Default_Value and the other doesn't, or where they both have it
but don't have a common ancestor. Clearly a derived type and its parent have 
a common ancestor, and clearly you can't get rid of a Default_Value aspect 
when you have it, so the only issue is adding a Default_Value aspect.

[From Randy Brukardt:]

This rule has the advantage that it could be compatibly relaxed in the future 
(perhaps to "require overriding"), if it proves to be a problem. Other rules 
would probably require an incompatible change to be made more friendly.

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

From the WG 9 review, issue #116.

4.2.1(7/5) says:

    ... The actual parameter of this notional call is a string_literal having 
    the textual representation of the original (numeric or string) literal.

Does the textual representation of a string literal include the quotes on 
either end? And what about doubled quotation marks occurring in the middle?
Based on the example of Roman_Number, I would guess the answer is the 
enclosing quotes are removed, and a doubled quotation mark becomes a single 
quotation mark, but that is not clear from this rule. I would suggest the 
following:

    ... The actual parameter of this notional call is a string_literal having 
    the textual representation of the original (numeric or string) literal{; 
    in the case of a string literal, the enclosing quotation marks from the 
    original textual representation are not included, and doubled quotation 
    marks in the textual representation are represented by a single quotation
    mark in the actual parameter}.

---

On further thought, the string literal case to some extent makes more sense 
than the numeric literal case. How can a string literal have the same textual
representation as a numeric literal? At a minimum it needs enclosing quotation
marks. I think part of the confusion here is that we are swinging between a 
syntactic view and a semantic view, while not always being clear which one we 
mean at any given time. So perhaps this should be changed as follows:

    ... The actual parameter of this notional call is a string_literal 
    {representing a sequence of characters that is the same as the sequence 
    of characters in the original numeric literal, or the sequence represented 
    by the original string} [having the textual representation of the original 
    (numeric or string)] literal.

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

From the WG 9 review, issue #176.

AI12-0355-2 starts as follows:

    All constructs that include the word "parallel" now permit an
    aspect_specification as part of their syntax.

    !problem

    We need a mechanism to pass information through to a lightweight
    parallelism scheduler. Something like an aspect specification might be a
    good way to specify such options.

    !proposal

    We propose to add an aspect_specification to every place the PARALLEL
    keyword is envisioned currently ...

In fact, we somehow missed the parallel block feature. All of the above logic
applies to a parallel block, so it makes sense to allow an aspect clause 
there. Hence, 5.6.1(2/5) should probably be replaced with

parallel_block_statement ::= 
    parallel [aspect_specification] do
       handled_sequence_of_statements
    and
       handled_sequence_of_statements
   {and
       handled_sequence_of_statements}
    end do;

The "static semantics" section is mislabeled, and should be labeled "dynamic 
semantics" (also mentioned by Issue #169). RM 5.6.1(3/5) should be updated as
follows:

   {For the execution of a parallel_block_statement, the aspect_specification, 
   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{, 
   each of which} represents a separate logical thread of control{, 
   executes}[ that proceeds] independently and concurrently. The 
   parallel_block_statement is complete once every one of the 
   handled_sequence_of_statements has completed, either by reaching the end 
   of its execution, or due to a transfer of control out of the construct by
   one of the handled_sequence_of_statements (see 5.1).

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

Inspired by the above:

All of this (incorrect) talk about visibility and resolution of aspect
 specifications along with thinking about adding aspect_specifications to 
parallel blocks (and other statements and expressions) caused me to wonder 
about resolution in those aspect_specifications.

Specifically, 13.1.1(11/5) says:

The usage names in an aspect_definition are not resolved at the point of 
the associated declaration, but rather are resolved at the end of the 
immediately enclosing declaration list, or in the case of the declaration 
of a library unit, at the end of the visible part of the entity.

What if this aspect_definition is part of an aspect_specification that's 
in a loop or block or if statement etc??? What the heck declaration list 
are we talking about -- the one enclosing the body is way too late and there
isn't one in the sequence_of_statements. (It's better for an 
aspect_specification in an expression, such as an aggregate or quantified 
expression, if that expression is part of some declaration, but it still 
means resolution is mighty late. Of course, we have a rule - 13.1.1(13/3) - 
that the resolution has to match at the freezing point of the declaration, 
but how that applies to an expression that is only loosely tied to a 
declaration isn't clear.)

I think we patched up the freezing rules for this statement/expression case 
(yes, we did, see 13.14(7.2/5)), but not the resolution rules. Yikes!!

Am I right? Do we have a significant last minute issue here??

[Tucker Taft replied:]

I agree that we should limit the notion of "deferred" name resolution to cases
where we are talking about an aspect specification on a declaration.  Hence:

Modify 13.1(11/5):

The usage names in an aspect_definition {associated with a declaration}
[Redundant: are not resolved at the point of the associated declaration, but
rather] are resolved at the end of the immediately enclosing declaration list,
or in the case of the declaration of a library unit, at the end of the visible
part of the entity.


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

From the WG 9 review, issue #132 - Steve Baird.

We could quibble over 13.1/5 wording regarding "shall be legal as
the prefix of an Access attribute reference", since an Access
attribute reference normally occurs in some specific context
that, for example, defines its expected type. So it is, arguably at
least, not completely clear what this wording means.
[Randy suggests that this does indeed warrant some action, and that
the fix is easy.]

===

This also illustrates an RM consistency issue that should be
cleaned up at some point (but not now). Here we use the (good
& desirable) terminology "an Access attribute reference". At other places
in the RM (e.g., 6.1.1(8)), we use pedantic, contorted wording
like "an attribute_reference with attribute_designator Old".
That sort of thing should be replaced with "an Old attribute reference".

If it seems appropriate, we could add a definition saying that
an " attribute reference" is an attribute_reference
having the given attribute name as its attribute_designator. Or we
could decide that this is sufficiently obvious that it does not need
to be stated explicitly.

[Randy suggests either we should explicitly define this new term or
we should avoid the shorter terminology that I prefer. He doesn't like
using this shorter terminology without properly defining it. I'm
inclined to agree.]

[Tucker Taft responds:]

For the first part, I would suggest:
Modify 4.1.3(13.1/5):
For a prefixed view of a subprogram whose first {formal} parameter is an 
access parameter, the prefix shall be legal as the prefix of an Access 
attribute reference {appearing as the first actual parameter in a call on
the unprefixed view of the subprogram}.

[The Editor responds:]

The second part is easy to fix in this rule, just use the defined terminology:

Modify 4.1.3(13.1/5):
For a prefixed view of a subprogram whose first {formal} parameter is an 
access parameter, the prefix shall be legal as the prefix of an
{an attribute_reference with attribute_designator} Access 
[attribute reference] {appearing as the first actual parameter in a call on
the unprefixed view of the subprogram}.

No one is interested in spelunking the RM for other places where we use
inprecise terminology, and adding a term is too much at this point.

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

From the WG 9 review, issue #142 - Steve Baird.

The statically matching rule for Global aspects (4.9.1(1.5/5) says
... or each is of the form “global_mode global_designator” with
the same sequence of reserved words.
But a global_designator can be a global_name, so it seems like we need
a requirement that corresponding global_names have to statically denote
the same entity, or something like that.

[Tucker Taft responds:]

I would suggest:

Modify 4.9.1(1.5/5)

   The Global or Global'Class aspects (see 6.1.2) of two entities statically
   match if both consist of a single global_aspect_definition where each is 
   the reserved word null, or each is of the form 
   “global_mode global_designator” with {each global_mode being} the same
   sequence of reserved words {and each global_designator being the same 
   reserved word, or each being a global_name that statically denotes the 
   same entity}.

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

From: Tucker Taft
Sent: Monday, May 31, 2021  11:14 AM

Item (14) of this AI proposes the wording change to parallel blocks given 
below, to include an aspect_specification, as with all other parallel 
constructs.  I realized as I have been putting together a tutorial on the 
various Ada 2022 parallel constructs for Ada-Europe, that we should also 
include a chunk count for a parallel block, as we have for essentially all
other parallel constructs.  This is because a typical recursive divide and
conquer parallel algorithm will want to use a parallel block, but will also
want to control the number of logical threads spawned to handle the parallel
block, as the nesting of recursion increases.  The easiest way to do this
programmatically is to have the chunk count go to one once sufficient
parallelism has been produced, or the problem has gotten sufficiently small.

Note that in OpenMP there is always an ability to turn off further parallelism
under similar circumstances, by having such a limit on the number of threads
devoted to the construct.  As part of adding the aspect_specification to a
parallel_block_statement, it makes sense to include a chunk_specification,
but with the same restriction as is present for a parallel reduction, namely
that the chunk_specificaiton is required to be an integer simple_expression
(i.e. no named chunk parameter).

Below I first give the wording change as initially proposed by AI12-0427-1, 
and then an alternative, which includes the chunk_specification.

=====================

Here is the proposal from AI12-0427-1:

(14) Replace 5.6.1(2/5) with:

parallel_block_statement ::= 
    parallel [aspect_specification] do
       handled_sequence_of_statements
    and
       handled_sequence_of_statements
   {and
       handled_sequence_of_statements}
    end do;

Modify 5.6.1(3/5):

   {For the execution of a parallel_block_statement, the aspect_specification, 
   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{, 
   each of which} represents a separate logical thread of control{, 
   executes}[ that proceeds] independently and concurrently. The 
   parallel_block_statement is complete once every one of the 
   handled_sequence_of_statements has completed, either by reaching the end 
   of its execution, or due to a transfer of control out of the construct by
   one of the handled_sequence_of_statements (see 5.1).

====

And here is what I would now recommend:

(14) Replace 5.6.1(2/5) with:

  parallel_block_statement ::= 
    parallel [(chunk_specification)] [aspect_specification] do
       handled_sequence_of_statements
    and
       handled_sequence_of_statements
   {and
       handled_sequence_of_statements}
    end do;

  The chunk_specification, if any, of a parallel_block_statement shall be an 
  /integer_/simple_expression.

Modify 5.6.1(3/5):

   {For the execution of a parallel_block_statement, the chunk_specification 
   and the aspect_specification, if any, are elaborated in an arbitrary order.
   Then every}[Each] handled_sequence_of_statements{, each of which can} 
   represent[s] a separate logical thread of control{ (up to the maximum
   specified by the value of the chunk_specification, if any), executes}[ that
   proceeds] independently and concurrently{, again, up to the maximum if 
   specified}. The parallel_block_statement is complete once every one of the 
   handled_sequence_of_statements has completed, either by reaching the end 
   of its execution, or due to a transfer of control out of the construct by
   one of the handled_sequence_of_statements (see 5.1).

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

From: Randy Brukardt
Sent: Friday, June 4, 2021  11:47 PM

I noticed some minor problems with the rewording of 5.6.1(3/5) in AI12-0427-1. 
A summary of a private thread between Tucker and I is given below.

We intend to process this rewording of the rewording as an Editorial Review 
change. It is a bit of a stretch for that (the missing check represents added
semantics, even if obviously missing semantics). Therefore, if anyone wants to
request a Letter Ballot on this change (essentially, objecting to handling
this as an Editorial Review change), please speak up ASAP.


Summary of private thread:

From Randy Brukardt:

We have in 5.6.1(3/5):

   {For the execution of a parallel_block_statement, the chunk_specification 
   and the aspect_specification, if any, are elaborated in an arbitrary order.
   Then every}[Each] handled_sequence_of_statements{, each of which can} 
   represent[s] a separate logical thread of control{ (up to the maximum
   specified by the value of the chunk_specification, if any), executes}[ that
   proceeds] independently and concurrently{, again, up to the maximum if 
   specified}. The parallel_block_statement is complete once every one of the 
   handled_sequence_of_statements has completed, either by reaching the end 
   of its execution, or due to a transfer of control out of the construct by
   one of the handled_sequence_of_statements (see 5.1).

I won't mention the department of redundancy department repeat of the maximum 
(there's nothing like it in the loop wording). 

But two things seem to be missing here:
   First, how do the limbs of a parallel block execute if there aren't enough 
   logical threads of control for all of them? Previously, there always were
   enough logical threads, and they could be mapped to physical threads
   however the implementation wished. But now we seem to have a limit on the
   number of logical threads, and we never say anything about how a limb
   executes if it doesn't have a thread.

   Second, for loops have a check to ensure that the number of chunks is 
   positive (see 5.5(8.1/5)). This is implied (very weakly!!) for reduction
   expressions via the references to 5.5 in 4.5.10(20-21/5). But we have no
   such check here, nor even a way to hand-wave a check via a reference to 
   the check in 5.5.

So, what happens with 
     parallel (-2) do
       ...
     end do;

One would hope this raised Program_Error like a loop would. But why??

From Tucker Taft:

> First, how do the limbs of a parallel block execute if there aren't 
> enough logical threads of control for all of them?

My intent was that they execute independently and concurrently only if we 
stay within the maximum.  Otherwise, they execute sequentially.  But I agree 
that my attempt to avoid complete rewrite was doomed.

...
>One would hope this raised Program_Error like a loop would. But why??

Agreed, we should be consistent here.

Here is my attempt. I have given up on using {} and [] to indicate what is 
new and what is pre-existing.  I have dropped the "handled_" part ;-)

Replace 5.6.1(3/5) with:

  For the execution of a parallel_block_statement, the chunk_specification
  and the aspect_specification, if any, are elaborated in an arbitrary order.
  The various
  sequence_of_statements are grouped into one or more /chunks/, each with
  its own logical thread of control (see clause 9), up to the maximum number
  of chunks specified by the chunk_specification, if any. Within each chunk
  every sequence_of_statements of the chunk is executed in turn, in an
  arbitrary order. The parallel_block_statement is complete once every one
  of the sequence_of_statements has completed, either by reaching the end of
  its execution, or due to a transfer of control out of the construct by one
  of the sequence_of_statements (see 5.1). After elaborating the
  chunk_specification, if any, a check is made that the determined maximum
  number of chunks is greater than zero. If this check fails, Program_Error
  is raised.

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

From: Jeff Cousins
Sent: Saturday, June 5, 2021  2:29 AM

Shouldn't last two sentences of the new wording come after the first sentence?

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

From: Randy Brukardt
Sent: Sunday, June 6, 2021  12:53 AM

I wondered that, too. I eventually concluded it didn't matter that much, but 
the loop wording uses two separate paragraphs. Here, that would look something
like:
 
Replace 5.6.1(3/5) with: 

  For the execution of a parallel_block_statement, the chunk_specification 
  and the aspect_specification, if any, are elaborated in an arbitrary order.
  After elaborating the chunk_specification, if any, a check is made that the
  determined maximum number of chunks is greater than zero. If this check
  fails, Program_Error is raised. 

  Then, the various sequence_of_statements are grouped into one or more
  /chunks/, each with its own logical thread of control (see clause 9), up to
  the maximum number of chunks specified by the chunk_specification, if any. 
  Within each chunk every sequence_of_statements of the chunk is executed in 
  turn, in an arbitrary order. The parallel_block_statement is complete once 
  every one of the sequence_of_statements has completed, either by reaching
  the end of its execution, or due to a transfer of control out of the
  construct by one of the sequence_of_statements (see 5.1). 
 
Not certain if this is better, but it's more consistent with the wording for 
the parallel loops. Agree? Disagree? Don't care? ;-)
 
****************************************************************

From: Jeff Cousins
Sent: Sunday, June 6, 2021  2:38 AM

That seems much better to me.  Otherwise we might need another AI later to 
clarify the order in which things happen (as with 343).

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

From: Tullio Vardanega
Sent: Sunday, June 6, 2021  7:52 AM

I agree this way is more consistent with the related wording.

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

From: Tucker Taft
Sent: Sunday, June 6, 2021  8:15 AM

Fine with me.

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