Version 1.50 of ai12s/ai12-0005-1.txt

Unformatted version of ai12s/ai12-0005-1.txt version 1.50
Other versions for file ai12s/ai12-0005-1.txt

!standard 6.6 (6)          11-11-11 AI12-0005-1/00
!class confirmation 11-11-11
!status received 11-11-11
!priority Low
!difficulty Easy
!qualifier Omission
!subject Editorial comments on AARM 2012
!summary
This AI serves as a holder for editorial comments on AARM-only annotations. This AI serves the same purpose as AI95-00114 did for Ada 2005 and AI05-0005-1 did for Ada 2012. Because the AARM has no official status as far as ISO is concerned, these will be considered low priority.
If a change cross-references this AI, find it in the Appendix below.
!question
!response
!appendix

From: John Barnes
Sent: Tuesday, May 22, 2012  3:11 PM

...
Anyway, I just downloaded the latest version and hunting around for incomplete types
and generics, I came across 12.5(16.i/3). It refers to AI-215 instead of AI-213. Rats.

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

From: Randy Brukardt
Sent: Monday, January 14, 2013  9:26 PM

AARM 3.9(12.d/2) uses "privateness", which is not a word. Use "privacy" instead.

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

From: Randy Brukardt
Sent: Monday, January 14, 2013  9:26 PM

AARM 9.6.1(4.a/2) has two minor errors. First there is a word missing:

"... which are more than 12 hours {different }than UTC. ..."

Second, "southern" is misspelled (the last 'n') is missing.

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

From: Randy Brukardt
Sent: Friday, April 19, 2013 1:21 AM

AARM 11.5(31.l/3) has a typo:

...inlining is never requir{ed}[ing],...

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

From: Tucker Taft
Sent: Tuesday, February 26, 2013   5:10 PM

I agree with both of you. [Editor's Note: The majority of this thread can be
found in AC-00248.]

The wording as given is inadequate, but the intent is
as Randy stated: you may assume that if you evaluate an assertion expression
once and it is True, you don't need to evaluate it again if all you are doing in
the mean time is evaluating assertion expressions.

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

From: Steve Baird
Sent: Tuesday, February 26, 2013   5:21 PM

I'm happy to leave it at that.

Let's either take no further action or, if anyone thinks it is worth the bother,
add a brief AARM note based on Tuck's words above.

*** Add an AARM note.

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

From: John Barnes
Sent: Friday, June 7, 2013   9:13 AM

The package Ada.Dispatching was Pure in Ada 2005 but has been downgraded to
Preelaborable because of the addition of Yield. This is unlikely to be a
problem. (AI-166, D.2.1)

*** Incompatibility not mentioned in AARM

When an inherited subprogram is implemented by a protected function, the first
parameter has to be an in parameter, but not an access to variable type. Ada
2005 allowed access to variable parameters in this case; the parameter will
need to be changed to access to constant by the addition of the constant
keyword. (AI-291, 9.4)

*** this is a BI, but it doesn't say correction in AARM

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

From: Randy Brukardt
Sent: Monday, June 15, 2013   9:43 PM

3.10.2(7.b/2) talks about anonymous access types used in stand-alone
type declarations and function results as having the level of the
declaration. But neither of these are true anymore (they also have
special rules). This note needs to be rewritten to talk only
about components.

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

From: Randy Brukardt
Sent: Thursday, October 24, 2013   9:43 PM

The thread in AC-00254 makes it clear that the "resolution" rules
4.6(7) and 6.4.1(4) are not actually used for resolving overloading
and the like. They exist specifically to prevent the "name" from
being evaluated (which would happen by 4.4(10)) if they are part
of an expression. That's why they used the weird wording of
"interpreted as" rather than "shall be". This needs to be much
clearer in the AARM Notes.

AC-00254 has an example program that illustrates some of the
oddities that would occur if these rules were used as resolution
rules. Tested compilers do not do so, thus we add the notes to
ensure that future compiler authors are not confused.

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

From: Steve Baird
Sent: Friday, November 15, 2013   4:57 PM

unhyphenated "class wide" in 6.5(5.d/3)

"if the result type is class wide, then there must be an expression ..."

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

From: Randy Brukardt
Sent: Wednesday, December 11, 2013   9:43 PM

There is an unhyphenated "classwide" in 6.8(5.b/3). "...and the static
classwide accessibility check cannot fail..." There are also
occurrences in 3.7.2(3.b/3) [two occurrences], 7.6.1(9.b/3),
7.6.1(24.ee/3), and E.2.2(20.j/3).

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

From: Adam Beneschan
Sent: Tuesday, February  4, 2014  10:03 AM

Is there a reason why the Shift_*** and Rotate_*** subprograms defined in
Interfaces (in B.2) aren't listed in Q.3, or was this an oversight?
They also don't have their own Index entries.  (By contrast, the subprograms
in Interfaces.C, defined in B.3, are in both places.)

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

From: Randy Brukardt
Sent: Wednesday, February  5, 2014  6:51 PM

I can't find any documentation of the reason, but I think I omitted them
because the contents of package Interfaces is formally implementation-defined.
(See B.2(1) and especially AARM B.2(1.a)).

As further evidence of this reasoning, note the difference between the handling
of these packages for restriction "No_Implementation_Identifiers". In
particular, all identifiers in Interfaces are considered implementation-defined
(13.12.1(2.11/3) and 13.12.1(2.15/3)), while only added identifiers in
Interfaces.C are considered implementation-defined (13.12.1(2.2/3) and
13.12.1(2.6/3)).

As such, they're not "language-defined" identifiers and thus they don't belong
in Annex Q. Note that you don't find Long_Integer or Short_Integer in Annex Q,
either. (Given the special handling for Long_Integer and Long_Float for the
purposes of restriction No_Implementation_Identifiers, perhaps they ought to
be there.)

They probably ought to be in the main index, but I probably forgot about them
simply because the usual command does all of that automatically (it adds a
subprogram to the Annex Q and main indexes with a single operation). Since I'm
not using the usual command, I ended up not using any command. I'll fix that
for future versions.

P.S. Note that the indexes are non-normative, so these are treated like
questions on the AARM; so this thread will be filed in AI12-0005-1 with other
AARM questions.

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

From: Adam Beneschan
Sent: Wednesday, February  5, 2014  7:21 PM

> I can't find any documentation of the reason, but I think I omitted 
> them because the contents of package Interfaces is formally 
> implementation-defined. (See B.2(1) and especially AARM B.2(1.a)).

B.2(1.a) looks a lot like 13.7(2.a/2), and the identifiers in System do appear
in Annex Q.  

But I'll allow there are other differences there.  13.7(2) says "The following
language-defined library package exists" about System, while B.2(2) doesn't use
the word "language-defined".  Also, the description of
No_Implementation_Identifiers lists System in the same category as
Interfaces.C. 

I guess it seems a bit odd to have an identifier that is
"implementation-defined" as opposed to language-defined, but that the language
requires implementations to define (since it's in the Implementation
Requirements section).  Also, the language does seem to define what the
identifier is supposed to do.  Perhaps these identifiers are is in some
in-between state between language-defined and implementation-defined---a
"Schrödinger's Identifier", maybe?  

Anyway, I was just wondering if the omission was a typo.  If there's a reason
behind it, that's OK with me (I don't normally look things up in Annex Q
anyway).

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

From: Randy Brukardt
Sent: Wednesday, February  5, 2014  8:04 PM

... 
> I guess it seems a bit odd to have an identifier that is 
> "implementation-defined" as opposed to language-defined, but that the 
> language requires implementations to define (since it's in the 
> Implementation Requirements section).  Also, the language does seem to 
> define what the identifier is supposed to do.  Perhaps these 
> identifiers are is in some in-between state between language-defined 
> and implementation-defined---a "Schrödinger's Identifier", maybe?

I think that's right. The problem here is while there is a requirement that
an implementation define a function Rotate_Left, the first argument to it has
a type that is clearly implementation-defined. (Most implementations will have
Unsigned_8, but other possibilities exist: our U2200 implementation had
Unsigned_9 but no Unsigned_8, for instance.) So it's in a weird limbo halfway
between language-defined and implementation-defined. Since 13.12.1 comes down
on the side of implementation-defined, the Annex Q indexes do the same.

> Anyway, I was just wondering if the omission was a typo.  If there's a 
> reason behind it, that's OK with me (I don't normally look things up 
> in Annex Q anyway).

The omission from the main index was clearly an oversight (although "rotate"
and "shift" are indexed). The omission from Annex Q was on purpose, I think.

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

Summary of private discussion between Steve Baird and Randy Brukardt,
Wednesday, February 26, 2014

Baird:

Given
    X : constant Positive := 0;

is X a static constant?

Brukardt:

Yes, of course
    X : constant Positive := 0;
is a static constant that's legal (and raises Constraint_Error at runtime).

It's weird but causes no problems, and any other answer would be incompatible
(see ACATS test B490001) and very bad for conditional compilation.

It causes no problems because no code/types/whatever that will ever execute
can depend on the value of X, and the value of the static expression is
well-defined (so we always know what to do at compile-time).

It's necessary so that conditional compilation works:

    if Static > 0 then
       declare
           Bits : constant Positive := Static;
           type Foo is range 0 .. (2**Bits)-1 with Size => Bits;
       begin
           ...

We don't want the legality of Foo to depend on the *value* of Static (which
it would if Bits is not a static constant when Static = 0), else the entire
conditional compilation idea falls over.

[4.9(34) causes many other such problems -- 2**Bits shows one of them -- but
we certainly don't want to introduce any more. Recall the hoops we jumped
through to allow conditional expressions to work as expected.]

Cases like the above show that the compatibility issue is significant, thus no
change of any kind is best.

Maybe we want an AARM note, but no more.

Baird:

> It's weird but causes no problems, and any other answer would be 
> incompatible (see B490001) and very bad for conditional compilation.

B490001's constant declaration would still be legal if we changed the
definition of "static constant" to include a requirement that the static value
belongs to the static subtype of the constant.

But your are still right that it could be incompatible.

This example is currently legal, but would become illegal:

    X : constant Positive := 0;
    function Foo return Natural is ... ;
  begin
    case Foo is
       when X => ...;
       when Positive => ...;
    end case;

So I agree that we would need a good reason to make such a change.

Is there any problem with having a static constant whose elaboration raises
an exception? Does this cause problems with preelaborability, purity, the
DSA, etc. ?

Brukardt:

I was asking you that! I can't think of any, specifically because the static
value (presuming the expression is otherwise legal) is well-defined. In this
case, 0. So the compiler just uses that (which it has to be able to do), and
nothing that depends on that value can ever actually be executed, so there is
no real problem.

I suppose you might get funny errors in some cases:

      X : constant Positive := 0;

      B : constant Boolean 10/X; -- Illegal, divide-by-zero

which is of course weird because you divided by a Positive value to ensure that
you couldn't divide by zero.

But I don't see that as worse than any other conditional compilation related
errors.

Purity seems to be syntactic (constant vs. variable).

Preelaboration seems to be better with the current rule. If we changed it, then
preelaboratability could depend on an imported value:

     X : constant Positive := Other_Pkg.Static;

     Y : constant Positive := X + 1; -- Better be static.

If X is not a static constant when Other_Pkg.Static = 0, then Y is not allowed
in a preelaborable package. That seems like a maintenance hazard (someone
changes a value, a package far away becomes illegal for an obscure reason, and
the fix is definitely non-trivial).

Note that C.4(11) seems to cover this case, not requiring no code to be
executed if the declaration raises an exception during elaboration.

I'm not going to try to figure out DSA.

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

From: Randy Brukardt
Sent: Friday, April 18, 2014  9:44 PM

13.14(10.m/3) has:

type Bar is access function Foo (A : in Natural) return Natural;

But the syntax of an access-to-subprogram does not have an identifier
where Foo is given; it should be deleted.

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

!topic        Ada.Direct_IO: Index after Create resp. Open
!reference  Ada 2012 RM A.8.2(3/2,7)
!from         Christoph Grein  2014-09-25
!discussion

Neither Create nor Open specify the value of Index, which will be used for Read
or Write, see A.8.5(3,6,11), for the very first access with the procedures
without the Positive_Count parameter (must be 1, of course).

Should this oversight be corrected?

[Editor's note: Most of this thread is filed in AC-00264.]

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

From: Egil Harald Hoevik
Sent: Thursday, October  2, 2014  1:33 AM

I believe that's covered by A.8(3-4)

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

From: Randy Brukardt
Sent: Thursday, October  2, 2014  1:51 PM

> I believe that's covered by A.8(3-4)

Thanks!

A.8(4) says "When a direct file is opened, the current index is set to one."
Hardly could be any clearer than that. Perhaps it isn't in the best possible
place, but it certainly is stated normatively.

[Editor's note: I added AARM notes to make this cross-reference more obvious.]

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

From: Randy Brukardt
Sent: Friday, October 10, 2014  8:58 PM

13.11.3(9.c/3) does not mention aspect Default_Storage_Pool (see
13.11.3(5/3)).

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

From: Randy Brukardt
Sent: Friday, February 13, 2015  8:12 PM

13.1.1(4.b/3) does not mention expression_function_declaration, it should be
added directly after null_procedure_declaration.

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

From: Steve Baird
Sent: Tuesday, March 10, 2015  6:48 PM

There may be no problem here, but the wording seems unclear to me.

If you think it is clear enough, I'll probably shut up (I say "probably" just
to reserve the right to change my mind).

In 4.1.6, we've got a new note
    The Constant_Indexing and Variable_Indexing aspects
    cannot be redefined when inherited for a derived type,
    but the functions that they denote can be modified by overriding
    or overloading.

I don't think the 4.1.6 wording makes it sufficiently clear that the set of one
or more functions denoted by a C_I/V_I aspect is recalculated when we declare
an extension. For example, if an ancestor type has C_I specified which denotes
two functions, might a descendant of that type have three C_I functions with
one inherited, one overriding, and one non-overriding? Presumably yes.

If the descendant type overrides an inherited C_I function of the ancestor
type, which function body gets executed for an indexing call if the prefix
is not class-wide? Presumably the overrider's.

How does all this work in a case like

    package Pkg1 is
      type T1 is tagged null record with Constant_Indexing => Foo;
      function Foo (X : T1; Y : Integer; Z : Integer := 123) return T1;
    end Pkg1;

    package Pkg2 is
       type T2 is new Pkg1.T1 with record F2 : Integer := 0; end record;
       overriding
       function Foo (X : T2; Y : Integer; Z : Integer := 456) return T2;
    end Pkg2;

    Aaa : Pkg.T2;
    Bbb : Pkg.T2 := Aaa (789);

? Presumably this is legal and the non-dispatching call returns a T2, not a T1
(and the actual parameter passed in for Z is 456, not 123).

It also seems a little odd that the equivalence rule which defines the dynamic
semantics of these guys (4.1.6 (17/3)) occurs in a "Name Resolution Rules"
section.

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

From: Steve Baird
Sent: Wednesday, March 11, 2015  1:42 PM

> If you think it is clear enough, I'll probably shut up (I say 
> "probably" just to reserve the right to change my mind).

After sleeping on it, I see that the crux of the matter is the name resolution
rule

   When a generalized_indexing is interpreted as a constant (or
   variable) indexing, it is equivalent to a call on a prefixed view of
   one of the functions named by the Constant_Indexing (or
   Variable_Indexing) aspect of the type of the
   indexable_container_object_prefix with the given
   actual_parameter_part, and with the indexable_container_object_prefix
   as the prefix of the prefixed view.

and, specifically, the meaning in the case of a derived type which inherits the
aspect of the phrase
     "the functions named by the Constant_Indexing (or
      Variable_Indexing) aspect of the type"
.

I know what set we want that phrase to denote (it is the set of subprograms
where the equivalent prefixed call would work as defined in 4.1.3(9.2/3)).

My question is whether the current wording captures that intent.

I think maybe it does and there is no problem, but I raise the question.

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

From: Randy Brukardt
Sent: Wednesday, March 11, 2015  2:38 PM

I agree ("maybe it does"). The wording says "named by" and not the more usual
"denoted by"; this means that it is the name of the function and not the
declaration that is denoted that matters. Thus one starts with the name each
time and then must figure out from that what is denoted. Obviously, that might
be different for a derived type vs. the original type.

What's not 100% clear to me is the implied (re-)resolution. Since one has a
name by the rule, and one needs a declaration in order to make a call, I don't
see how else one could arrive at a declaration. But it's not spelled out. Of
course, that's typical of name resolution rules; the actual name resolution
tends to be implicit in them.

Thus I conclude that there is no problem (although perhaps adding an additional
sentence to 4.1.6(17.c/3) would help future readers: "This equivalence is then
resolved in the normal way; the aspect specifies a name, it does not denote
declarations.")

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

Editor's note (April 2, 2015): All of the items above this
marker are included in the Corrigendum version of the AARM.

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

From: Tucker Taft
Sent: Sunday, April 26, 2015  5:54 PM

There is some lack of clarity in the RM relating to the use of a subtype with a
Static_Predicate that is declared in the scope of an "Ignore" Assertion_Policy.
For example, in AARM 5.4(13, 13.a) it says the following:

   13 Otherwise (the value is not covered by any discrete_choice_list,
      perhaps due to being outside the base range), Constraint_Error is raised.

   13.a  Ramification: In this case, the value is outside the base range of its
         type, or is an invalid representation.

13.a is not correct in the presence of subtype predicates.  An object can have
a "valid representation" and still have a value that does not satisfy its
Static_Predicate, and hence not be covered by any choice list.  This is easy to
accomplish if "pragma Assertion_Policy(Static_Predicate => Ignore)" applies
when the subtype is declared.  Hence 13.a should be refined to include the
case of a value that does not satisfy a Static_Predicate.

It should also be clarified that X'Valid being False does *not* mean that X has
an invalid representation.  If X is in the appropriate range, but does not
satisfy the predicates of its nominal subtype, then X'Valid will return False,
but X is still "valid."  This is confusing, and probably deserves a "user note"
somewhere.

More generally it might be appropriate to augment the AARM implementation notes
that say what happens with subtypes with Static_Predicates that are being
ignored.  In particular, it should be clarified that, given an object X of such
a subtype S, Constraint_Error is a possible outcome in "case" statements with X
as the case expression (the situation described in 5.4(13,13.a) above),
membership test "X in S" might return False, X'Valid might return False, etc.
Be that as it may, this is *not* erroneous execution.  The results are totally
predictable, repeatable, and portable (and potentially confusing ;-).

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

From: Robert Dewar
Sent: Sunday, April 26, 2015  7:05 PM

the case statement should definitely raise CE in my view (P.S. that is the
current treatment in GNAT).

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

From: Jeff Cousins
Sent: Monday, April 27, 2015  4:14 AM

5.4 13.a needs updating, but it's pretty clear from 5.4 13, 3.8.1 10.1/3,
11.4.2 10/3 and 4.9 26/3 that there should be a Constraint_Error.

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

From: Randy Brukardt
Sent: Monday, April 27, 2015  10:36 AM

...
> 13.a is not correct in the presence of subtype predicates.  
> An object can have a "valid representation" and still have a value 
> that does not satisfy its Static_Predicate, and hence not be covered 
> by any choice list.  This is easy to accomplish if "pragma 
> Assertion_Policy(Static_Predicate => Ignore)" applies when the subtype 
> is declared.  Hence 13.a should be refined to include the case of a 
> value that does not satisfy a Static_Predicate.

This just looks like a case where the editor (me) and the AI author (Bob)
failed to notice that AARM note needs updating. Hardly a big deal.
 
> It should also be clarified that X'Valid being False does
> *not* mean that X has an invalid representation.  If X is in the 
> appropriate range, but does not satisfy the predicates of its nominal 
> subtype, then X'Valid will return False, but X is still "valid."  This 
> is confusing, and probably deserves a "user note" somewhere.

In hindsight, this probably was a mistake; we should have left 'Valid to
validity and let people that wanted to get the predicates involved to use
memberships. But it is what it is; it's water over the bridge or under the dam
now. :-)

Perhaps a note is worthy. Are you drafting one?? (Or do I have to do
*everything*? :-)

> More generally it might be appropriate to augment the AARM 
> implementation notes that say what happens with subtypes with 
> Static_Predicates that are being ignored.  In particular, it should be 
> clarified that, given an object X of such a subtype S, 
> Constraint_Error is a possible outcome in "case"
> statements with X as the case expression (the situation described in 
> 5.4(13,13.a) above), membership test "X in S"
> might return False, X'Valid might return False, etc.  Be that as it 
> may, this is *not* erroneous execution.  The results are totally 
> predictable, repeatable, and portable (and potentially confusing ;-).

That seems unnecessary. This happened to be the absolute top priority on my
testing list (it has been for quite a while); that's partly because I had
sorted all of the items with the same priority in clause order, and something
in 3.2 doesn't have much chance of anything with the highest priority to occur
in front of it.

Anyway, I wrote those tests (two) tonight, so the ACATS now checks that
memberships, 'Valid, and for loops use the predicates even if disabled (and
that the checks are not actually made in subtype conversion contexts). So it's
hardly likely that any implementor will not be aware of those effects.

I just added an objective for 5.4(13) to check the Constraint_Error case (it
was previously marked as untestable, but clearly this case is testable).
Since it would be based on the test I wrote tonight, it probably will get
written in the coming weeks, so that shouldn't surprise anyone, either.
(Especially after we fix the AARM note.)

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

From: Bob Duff
Sent: Friday, May 15, 2015  5:50 AM

> This just looks like a case where the editor (me) and the AI author 
> (Bob) failed to notice that AARM note needs updating. Hardly a big deal.

I admit that when I wrote that AI, I wasn't thinking about Assertion_Policy.
So I'm not surprised there are bugs related to that.

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

From: Randy Brukardt
Sent: Monday, May 18, 2015  8:25 PM

AARM 3.9(18.c/2), referring to Generic_Dispatching_Constructor, says:

Note that any tagged type will match T (see 12.5.1). 

T is declared:
   type T (<>) is abstract tagged limited private;

The issue here is that while the note for formally correct, it fails to note
that some instances would be illegal anyway.

Specifically, if the tagged type A is a tagged incomplete view (from an
incomplete type, formal incomplete type, or limited with), using it as the
actual in an instance of Generic_Dispatching_Constructor is illegal by rule
(an actual type for a formal private type is not one of the places listed
where the name of an incomplete view is allowed).

Similarly, if the tagged type A is a tagged partial view before its completion
(from a private type or private extension), using it as the actual in an
instance of Generic_Dispatching_Constructor is illegal because the type will
be frozen by the instantiation, but that would violate 13.14(17) [or, if you
prefer, 7.3(5), or even 3.11.1(8) -- this rule is repeated three times in the
RM!].

Thus I suggest a simple rewrite of the AARM annotation:

Note that {almost} any tagged type {can be used in an instance of
Generic_Dispatching_Constructor}[will match T (see 12.5.1)]. {Using a tagged
incomplete view or a tagged partial view before the completion of the type in
such an instance would be illegal; all other tagged types can be used in an
instance of Generic_Dispatching_Constructor.}

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

From: Tucker Taft
Sent: Monday, May 18, 2015  10:05 PM

That's fine with me, though I don't think it is necessary.  Incomplete types
are just that, incomplete, and are not really "types" in the normal sense.
Also, freezing is almost always treated as an orthogonal issue.

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

From: Randy Brukardt
Sent: Monday, May 18, 2015  11:05 PM

Sure, if you're in language lawyer mode. (Although an incomplete type is
surely a (view of a) type; thinking it's not "really a type" caused all manner
of RM holes -- let's not go back there!) But I definitely don't like saying
"all" or "any" when we really mean "most". We have a strict no lying rule for
the AARM.

I realize that strictly speaking, the note *isn't* lying (the matching works,
other rules fail). But that seems like hair-splitting; only a language lawyer
will care precisely why something fails. Besides, I believe I wrote that note
(I wrote most of the Generic_Dispatching_Constructor proposals), and I think
I meant that you can instantiate the generic with any tagged type (assuming
you have an appropriate constructor function) -- which definitely is not true.

I did think about just sticking "complete" into the sentence (or maybe
channelling the old commercials with "virtually spotless" dishes and saying
"virtually all" :-), but I thought a more complete explanation would be more
useful. The private type case is not that obvious and bites people all the
time (that's why we've spent so much effort on work-arounds and alternative
rules), best to not sweep it under the rug as "just freezing, we don't need to
talk about that".

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

From: Tucker Taft
Sent: Tuesday, May 19, 2015  7:05 AM

> ... But I definitely don't like
> saying "all" or "any" when we really mean "most". We have a strict no 
> lying rule for the AARM. ...

Fair enough.  Go for it.

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

From: Jeff Cousins
Sent: Wednesday, May 27, 2015  6:33 AM

Randy's words seem an improvement.

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

!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-02-19
!discussion

This paragraph is a bullet with an incomplete sentence.
This is the previous version:

For determining whether one level is statically deeper than another when
within a generic package body, the generic package is presumed to be
instantiated at the same level as where it was declared; run-time checks
are needed in the case of more deeply nested instantiations.

This is the new content:

or generic function F

It looks like an error - there is no reason to insert "generic function" in
this paragraph - and also no /4 indication.

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

From: Randy Brukardt
Sent: Monday, March 21, 2016  11:33 PM

There's a chunk of junk in the consolidated RM that gets its own paragraph
number (as would happen with any junk floating around); there's nothing wrong
with the actual text (it just moved down one paragraph).

Since the problem is only in the consolidated RM (and not in the Corrigendum
or Ada 2012 Standard, the official documents), we just mention it here and
fix it without further ado. [Unfortunately, Christoph then raised some further
ado - Editor.]

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

!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-03-24
!discussion

I resend this since I've never received a reply from the list, so I suspect
the mail was lost somehow.

The error is in the version
   http://ada-auth.org/standards/rm12_w_tc1/RM-Final.pdf
but not in
  http://ada-auth.org/standards/aarm12_w_tc1/html/AA-3-10-2.html

Oh, now I see: the paragraph (20) is erroneously present. When removed, the
text is correct again.


I haven't checked the other versions.
-------- Weitergeleitete Nachricht --------
Betreff:  Ruined paragraph 
Datum:  Fri, 19 Feb 2016 13:08:56 +0100 
Von:  Christoph Grein

!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-02-19
!discussion

This paragraph is a bullet with an incomplete sentence.
This is the previous version:

For determining whether one level is statically deeper than another when
within a generic package body, the generic package is presumed to be
instantiated at the same level as where it was declared; run-time checks are
needed in the case of more deeply nested instantiations.

This is the new content:

or generic function F

It looks like an error - there is no reason to insert "generic function" in
this paragraph - and also no /4 indication.

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

From: Randy Brukardt
Sent: Thursday, March 24, 2016  11:37 PM

>	I resend this since I've never received a reply from the list, so I
suspect the mail was lost somehow.

I didn't think that it needed a reply.

> Oh, now I see: the paragraph (20) is erroneously present.
> When removed, the text is correct again.
	
Right, just a chunk of floating junk. I'd guess that I cached a copy of a
change block while I was inserting changes, and forgot to get rid of it when
done (that happens periodically, I just usually see it before anything gets
issued). The way the formatter works, anything at all gets a paragraph number.
[I've seen a single square bracket with a paragraph number.]

Since it only appears in the consolidated RM and AARM (but not the Ada 2012
Standard or Corrigendum), no formal action is needed. I repaired the source
files and regenerated the HTML (which is easy) - which is why the error has
magically disappeared from the online HTML. Regenerating the PDFs takes 4-6
hours (each needs a set of hand-repairs, and the only software that can make
the PDF without crashing is on a very slow ancient machine -- and there is 7
different PDF files). So I thought I'd wait until some time had passed for any
other errors to be reported.

We have a tool that compares RM and Corrigendum text, but it only compares
paragraphs that are supposed to have been changed. So it can't find extra junk
(nor can it find paragraphs left out of the Corrigendum, another annoyance).
Still is a lot better than nothing.

P.S. Was this reply long enough? ;-)

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

From: Christoph Grein
Sent: Friday, March 25, 2016  9:30 AM

> P.S. Was this reply long enough? ;-)

Oh sure, by Jove!

(I meant however the automatic list reply which I received this time.)

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

!topic Undeleted deleted paragraph
!reference Ada 2012 TC1 RM 3.3.1(19/2)
!from Christoph Grein 16-07-15
!discussion

In the Adobe Acrobat (.pdf) with changes from Ada 95 highlighted version, the
para indicated above (on page 66) is not crossed out.

The online HTML version (without highlighted changes) is OK.


I haven't checked the other versions.

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

From: Randy Brukardt
Sent: Thursday, July 21, 2016  6:05 PM

Must be a tools bug. It appears in that version, and *only* that version,
going back at least to the Ada 2005 RM. (All of the other RM formats and all
of the AARM formats I checked are OK.) At least that is always an unofficial
version; the critical version is RM-Final, and it is OK.
 
Until it can be fixed, I suggest crossing the paragraph out with a pen on your
printed copy, and using a different electronic version.

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

From: Steve Baird
Sent: Thursday, October 6, 2016  2:06 PM

In AARM 13.1 we've got

   22.d
   The above code should instead be written like this:
   22.e
     Y : constant Address := G(...);
     X : Integer := F(...);
     for X'Address use Y;

Should the last two lines be replaced with

     X : Integer := F(...) with Address => Y;

?

I figured you'd want to hear about this while you are dealing with all the
last-minute stuff just before an ARG meeting.

[Editor's note: changed 13.1(14.c, 14.d, 22.b, and 22.e to use
aspects.]

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

From: Tucker Taft
Sent: Tuesday, May 2, 2017  11:52 AM

I bumped into the following when looking for cases where dynamic accessibility
checks occur.  The rule for array type conversion talks about access
parameters, but I don't see how they are relevant to this issue:

In section 4.6, in the dynamic semantics for Array Type Conversion:

39.1/2
{AI95-00392-01} If the component types of the array types are anonymous access
types, then a check is made that the accessibility level of the operand type
is not deeper than that of the target type.

39.b/2
Reason: This check is needed for operands that are access parameters and in
instance bodies. Other cases are handled by the legality rule given previously.

---

I would suggest we drop the mention of access parameters here.  Since the
designated type of the access parameter is necessarily a named type, even when
converting X.all where X is "access Array_Of_Anon_Acc" you know the level of
the components of Array_Of_Anon_Acc.

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

From: Randy Brukardt
Sent: Thursday, May 11, 2017  12:10 AM

> I bumped into the following when looking for cases where dynamic 
> accessibility checks occur.

Careful: you might convince me to issue more ACATS tests on that. ;-)

> The rule for array type
> conversion talks about access parameters, but I don't see how they are 
> relevant to this issue:

You mean the AARM note, obviously not normative.

> In section 4.6, in the dynamic semantics for Array Type Conversion:
> 
> 39.1/2
> {AI95-00392-01} If the component types of the array types are 
> anonymous access types, then a check is made that the accessibility 
> level of the operand type is not deeper than that of the target type.
> 
> 39.b/2
> Reason: This check is needed for operands that are access parameters 
> and in instance bodies. Other cases are handled by the legality rule 
> given previously.
>
> ---
> 
> I would suggest we drop the mention of access parameters here.  Since 
> the designated type of the access parameter is necessarily a named 
> type, even when converting X.all where X is "access Array_Of_Anon_Acc" 
> you know the level of the components of Array_Of_Anon_Acc.

I tried to figure out where this particular note came from, but it doesn't
seem to be mentioned anywhere. So it's possible I just copied it from the
access version 4.6(48.a), without enough thought.

Assuming that Mr. Baird agrees with this change (he can find ways to cause
issues that defy the rest of us!), I'll just make it (like other AARM note
changes, those do not go on the agenda or get discussed at the ARG level).
[Steve, I'd like a positive answer that you agree with Tuck.]

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

From: Steve Baird
Sent: Thursday, May 11, 2017  8:44 AM

> Assuming that Mr. Baird agrees with this change...
I agree with Tuck.

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

[Editor's note: The following is a heavily edited part of a private thread 
not related to the Ada Standard.]

From: Gary Dismukes
Sent: Tuesday, August 8, 2017  7:29 PM

Consider:

   package Aspects is
      X : constant Integer;

      type A is new Natural with Size => X;

   private
      X : constant Integer := Integer'Size;
   end Aspects;

One might think that the expression for aspect Size should be static, though
clearly "X" is not a static expression here, since it refers to a deferred
constant.  If it's required to be static, then it's illegal, but there seem
to be no rules that require the expression of the aspect to be static (though
if it were to be given in an attribute_definition_clause for Size it would
have to be static, by 13.3(48)), which is more than a bit surprising to us.
Our expectation is that specifying the Size as an aspect would be subject to
the same static restriction as the attribute clause.  (If for some reason
X *is* considered static here, then this would be illegal, as a consequence
of 13.14(7.2/3).)

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

From: Randy Brukardt
Sent: Tuesday, August 8, 2017  8:47 PM

13.3(48) applies to aspect specifications via the equivalence rule of
13.1.1(31/3). If that wasn't true, we'd have to repeat all of the Legality
Rules and details for specifying each attribute when specifying as an aspect,
which would completely defeat the purpose of this equivalence. The Dewar rule
at a minimum says that all of 13.3 applies to the similar aspects.

Perhaps it would be good to add an AARM note, or even a bit of wording, to this
equivalence to make it clear that all of the rules for attribute specification
apply to aspect specification. But the entire intent would be broken if this
was not the case.

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

From: Steve Baird
Sent: Wednesday, August 9, 2017  2:22 PM

> Perhaps it would be good to add an AARM note, or even a bit of 
> wording, to this equivalence to make it clear that all of the rules 
> for attribute specification apply to aspect specification. But the 
> entire intent would be broken if this was not the case.

Agreed on both points.
I think clarification is needed here.

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

From: Randy Brukardt
Sent: Wednesday, August 9, 2017  11:09 PM

I'm leaning toward an AARM Note, because I can add those without getting a
full ARG discussion involved. I don't want to rewrite all of 13.3 and parts
of 13.11 and other clauses. (Likely to introduce a lot of bugs.)

The note would say something like:

AARM Ramification: Unless specified otherwise, all of the requirements on
specifying a specific aspect with an attribute_definition_clause also apply
to the an aspect_specification for the aspect. For instance, for the Size
aspect for the subtype, the expression has to be a static expression with
an integer type and nonnegative value, all of the recommended level of
support requirements apply if Annex C is supported, and so on.

OK? If not, I'll trust that you'll take the question to the ARG list. (I
don't want to cause the "wrath of Bob", especially as this equivalence
semantics was his idea.)

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

From: Steve Baird
Sent: Thursday, August 10, 2017  11:13 AM

> AARM Ramification: Unless specified otherwise, all of the requirements 
> on specifying a specific aspect with an attribute_definition_clause 
> also apply to the an aspect_specification for the aspect. For 
> instance, for the Size aspect for the subtype, the expression has to 
> be a static expression with an integer type and nonnegative value, all 
> of the recommended level of support requirements apply if Annex C is
> supported, and so on.

Looks good, and I agree that adding AARM wording is the right thing to do
here.

Some minor wordsmithing:

   AARM Ramification: Unless specified otherwise, all of the requirements
   [for] {on} specifying a specific aspect with an
   attribute_definition_clause also apply
   to [an] {the} aspect_specification for the aspect. For instance, when
   [specifying] the  Size aspect [of a] {for the} subtype, the expression
   has to be a static expression with an integer type and [a] nonnegative
   value, all of the recommended level of support requirements apply if
   Annex C is supported, and so on.

I'd also consider using "particular" instead of "specific" just because we
are already talking about specifications. Ditto for "example" instead of
"instance" just because somebody searching the RM for "instance" probably
doesn't want to see this.

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

From: Randy Brukardt
Sent: Thursday, August 10, 2017  9:54 PM

...
> Looks good, and I agree that adding AARM wording is the right thing to 
> do here.

Thanks, and good.

> Some minor wordsmithing:
> 
>    AARM Ramification: Unless specified otherwise, all of the requirements
>    [for] {on} specifying a specific aspect with an
>    attribute_definition_clause also apply
>    to [an] {the} aspect_specification for the aspect. For instance, when
>    [specifying] the  Size aspect [of a] {for the} subtype, the expression
>    has to be a static expression with an integer type and [a] nonnegative
>    value, all of the recommended level of support requirements apply if
>    Annex C is supported, and so on.

You confused the heck out of me by getting the insertions and deletions
backwards. I couldn't figure out why you were deleting the better version in
most of the text. Finally, I went carefully back to the original and figured
out the problem.

> I'd also consider using "particular" instead of "specific" 
> just because we are already talking about specifications. 
> Ditto for "example"
> instead of "instance" just because somebody searching the RM for 
> "instance" probably doesn't want to see this.

Makes sense.

I added a sentence about these rules being enforced at the freezing point (like
all other aspect rules), after rereading Gary's original question. I wanted it
to be clear that A is legal below:

   package Aspect2 is
      X : constant Integer;
   private
      type A is new Natural with Size => X; -- OK, does not freeze X.
      type B is new Natural with Size => X;
      Obj : B; -- Illegal, freezes B and X, and X is not completed yet.
      X : constant Integer := Integer'Size;
   end Aspect2; -- A frozen here.

The whole thing would be legal if Obj was removed; when A is frozen, X is
resolved to a static constant.

Anyway, I've added the following to the draft AARM. Coincidentally, that
should be posted with the minutes tomorrow -- talk about service! :-)

    AARM Ramification: Unless specified otherwise, all of the requirements
    for specifying a particular aspect with an attribute_definition_clause also
    apply to an aspect_specification for the aspect. These are enforced at the
    freezing point of the entity. For example, when
    specifying the Size aspect of a subtype, the expression
    has to be a static expression with an integer type and a nonnegative
    value, all of the recommended level of support requirements apply if
    Annex C is supported, and so on.

            Randy.

P.S. You could argue that this is a To Be Honest note rather than a
Ramification, but that's the sort of useless argument that I'd prefer
to avoid.

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

From: Steve Baird
Sent: Friday, February 8, 2019  12:51 PM

Does it seem odd to you that the Ada.Strings.Unbounded spec doesn't seem to
rule out constructing a string longer than Integer'Last?

If you concatenate, for example, two strings whose lengths add up to more than 
Integer'Last, it seems like an exception ought to be guaranteed to result 
(obviously storage_error is possible, but I'm saying that it should be 
guaranteed that the call does not return normally).

It's not documented what the Length function is supposed to do with such a 
string. Presumably it raises Constraint_Error, but that's not stated.

Better IMO to leave the spec for Length unmodified and instead rule out this 
case by preventing construction of such a too-long string.

What do you think?

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

From: Randy Brukardt
Sent: Friday, February 8, 2019  4:16 PM

I don't know if it is "odd", but it certainly isn't possible. Janus/Ada raises 
Constraint_Error in that case (and since Integer is 16-bit in Janus/Ada, it 
does come up periodically. I even had to make a Long_Unbounded_String that 
uses Long_Integer indexes for some projects.), but that might be just because 
that's what happens in the Ada code.

That is
    Str.Length := Str1.Length + Str2.Length; 
overflows in the case in question. I never made any attempt to prevent it, 
because what else could it do?

(Looks at wording).

Actually, in the case of "&", the wording does say that Constraint_Error is 
raised in this case. It is defined in terms of the String "&", and that would 
have an upper bound outside of the index subtype of Natural, which would raise
Constraint_Error by 4.5.3(8). Indeed, an implementation that allowed 
Unbounded_Strings longer than Natural would be wrong for "&".

Append is defined in terms of "&", so it too is covered.

And the others like Replace_Slice and Insert are defined in terms of 
Ada.Strings.Fixed operations, which I hope (I didn't check) would also check 
the index subtype.

So I conclude there is no problem here. (Any problem is in Ada.Strings.Fixed.)

It might make sense to have an AARM note that mentions this; I certainly agree 
that this is a non-obvious ramification. (We can just do that, no need to 
involve anyone else.)

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

From: Edmond Schonberg
Sent: Monday, February 11, 2019  1:54 PM

Subject: infinitesimal glitches in the AARM

(with corresponding priority).  I came across the following in the latest 
version (I have to say that the amount of work that you
have put and continue putting into this is beyond awesome!):

2.9 (3.g/5) : 2012=> 2020

3.10.2 (23.r/4) : (is) leads  [Editor's note: this is really 3.10.1 (23.r/4).]

6.1.1 (41.e/4) these are not [be] allowed

6.3.1 (10.a/2) different than => different from

For the last one I’ll defer to a native speaker, but “different than” grates 
to my ears. It’s like using a comparison operator rather than
an equality operator!

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

!topic ... In contrast, a[n] loop parameter of an iterated_component_association takes ...
!reference Ada 202x RM4.3.3(23.c/5)
!from Christoph Grein 19-02-20

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

From: Randy Brukardt
Sent: Wednesday, February 20, 2019  6:03 PM

Got it!

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

!topic Jorvik
!reference Ada 202x AARM D.13(7.a/3,7.b/5)
!from Christoph Grein 19-02-20
!discussion :
There is a note (7.a/3) on where the name Ravenscar comes form.
Shouldn't there be a similar note on (7.b/5) where the name Jorvik comes from 
and how it is pronounced? It's far enough from normal English rules so that 
everyone will say Zhorvik without such a remark.
(It's like the Runge-Kutta method, which to the dismay of Germans is 
pronounced runzh-cutta, while both are Germans and the names are pronounced 
approximately roo-ng-e and koottah.)

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

From: Randy Brukardt
Sent: Wednesday, February 20, 2019  6:06 PM

Probably a good idea. I took the sentence from the AI that had that 
information, and added it as a note.

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

From Jeff Cousins' RM review:

E.2.2 (20.j/4) Added rules for {the} returning of remote ...

E.2.3 (19.a/4) ... all indirect or dispatching remote subprogram calls from 
outside the RCI unit{,} and all direct calls from outside the subsystem 
rooted at the RCI unit{,} are ...

 
E.2.3 (19.b/4) There is no point [to force]{in forcing} local ...

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

From Bob Duff's RM review:

4.6(7.a/4): This matters [as]{because}...

4.6(24.q/4): [recheck]{rules}

4.6(71.x/4): Hyphenate assume-the-worst.  ... unlikely [as]{because}...

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

From Steve Baird's RM review:

3.10.2(7.b/4) says (as per AI12-0005)
      "... as well as the accessibility level of anonymous access types in a
         component_definition"
   Should "in" be replaced with "defined by"? [Yes - Editor.]

In 3.10.2(19.3/4) we say
     "... when within ... or the return expression of expression function F,
     the <blah blah blah> is presumed to be the same as that of the level of
     the master that elaborated the body of F."
Is it ok to talk about elaborating the body of an expression function?

[Editor's reply:
It's bit iffy, because there isn't a static definition of the "body" of an 
expression function. But the only way to reword this would require a separate 
(and long) sentence only about expression functions. That seems like overkill. 
I added a To Be Honest note about this:

    For an expression function F, the "body of F" is the 
    expression_function_declaration of F.]

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

From: Bob Duff
Sent: Monday, April 1, 2019  2:49 PM

Maybe you can handle this as a simple editorial fix in 2.3:

4.1/5 {AI12-0004-1} {AI12-0263-1} An identifier shall only contain characters 
that may be present in Normalization Form KC (as defined by Clause 21 of 
ISO/IEC 10646:2017).

4.b/5       Implementation Note: An implementation can usually detect this
            during lexical processing. The code points not allowed are those
            for which Unicode property NFKC_QC (Normalization Form KC
            Quick_Check) has the value No. We say "might be allowed" so that

No, we don't.  We say "may be present".

            characters for which the value is Maybe (really, one of the
            possible values is Maybe) are allowed (these are mainly combining
            marks). The necessary tables can be found in
            http://www.unicode.org/Public/UCD/latest/ucd/DerivedNormalizationProps.txt
            . Versions for older Unicode versions can be found on this site as
            well; start at http://www.unicode.org/Public/ and find the
            appropriate version number.

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

From Ed Schonberg's RM review:

12.5.1 (5.g/4)      types [that differ from the kind] {whose 
kind differs from that of}

12.6 (8.e.2/5) ..of [an] {a} formal abstract subprogram.
 
> 13.1.1 (18.c/5)  … they all have to specify the same 
> [primitive of T]  value for that aspect  )?)   Explanation is garbled.

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

From Tucker Taft's RM review:

8.1(18.t/4)
... Note that some implementations already allow this common 
sense interpretation, so this extension [may]{might} in fact 
{already} be used in existing code. 

8.5.1(4.a/5)
   [This rule prevents] {These rules prevent} "lying". ...

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

From Brad Moore's RM review:

13.14(3.g/4) Ramification: Note that the rule about proper 
bodies [being]{causing} freezing only applies in declarative_parts.

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

From: Steve Baird
Sent: Tuesday, May 28, 2019  5:04 PM

[From private mail.]

>> AFAIK, there are no restrictions on calling 
>> Task_Identification.Current_Task during the execution of a parallel 
>> construct.
>>
>> Should there be? I don't think so, but I raise the question.
> 
> I don't see any problem here, a task /= LToC. The id would be in the 
> TCB somehow, and that has to be accessible from any thread executing 
> on behalf of that task (for things like task attributes as well as the
> task id).

Ok.

...
>> Do we want a C.7.1 AARM note saying something about interactions with 
>> parallel constructs, just for clarification?
> 
> Doesn't seem necessary, seems obvious to me. But what would you suggest??
> (We don't need to do anything "official" to add such a note, someone 
> needs to author it and I can just add it.)
> 

If it seems obvious then I'm fine with no action.

Would there be any value in something like

    The logical threads of control associated with the execution
    of a given parallel construct all execute as part of the execution of
    one task. Thus, the result returned by a call to
    Task_Identification.Current_Task is independent of whether the call
    takes place during the execution of a parallel construct.

? "No" is a fine answer.

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

From: Pascal Pignard
Sent: Wednesday, October 9, 2019  11:56 PM

[From private mail.]

I've read the AARM 202x draft 22 (text version).

Section 12.3 Generic Instantiation, I've found:
- Paragraph 15:
15.h            type T1 is tagged record ... end record;
15.i            generic
                    type Formal is new T1;
                package G is
                    type Derived_From_Formal is new Formal with record ... end record;
                    procedure Foo(X : in Derived_From_Formal); -- Does not override anything.
                end G;
15.j            type T2 is new T1 with record ... end record;
                procedure Foo(X : in T2);
15.k            package Inst is new G(Formal => T2);

== As T1 is tagged, Formal needs "with private", as:
type Formal is new T1 with private;

Is it correct?

- Paragraph 22:
22.e            generic
                    type T1 is private;
                    -- A predefined "=" operator is implicitly declared here:
                    -- function "="(Left, Right : T1) return Boolean;
                    -- Call this "="(1).
                package G is
                    subtype S1 is T1; -- So we can get our hands on the type from
                                      -- outside an instance.
                    type T2 is new T1;
                    -- An inherited "=" operator is implicitly declared here:
                    -- function "="(Left, Right : T2) return Boolean;
                    -- Call this "="(2).

22.f                T1_Obj : T1 := ...;
                    Bool_1 : Boolean := T1_Obj = T1_Obj;

22.g                T2_Obj : T2 := ...;
                    Bool_2 : Boolean := T2_Obj = T2_Obj;
                end G;

== As T1 is a private formal  type, so unknown, and therefore T2 unknown as 
well (derived from T1), what initial value could be given for T1_Obj and 
T2_Obj? Should be added a formal function? as:
with function Init return T1;
So:
T1_Obj : T1 := Init;
T2_Obj : T2 := T2 (Init);
Thus:
22.h            package P is
                    type My_Int is new Integer;
                    -- A predefined "=" operator is implicitly declared here:
                    -- function "="(Left, Right : My_Int) return Boolean;
                    -- Call this "="(3).
                    function "="(X, Y : My_Int) return Boolean;
                    -- Call this "="(4).
                    -- "="(3) is hidden from all visibility by "="(4).
                    -- Nonetheless, "="(3) can "reemerge" in certain circumstances.
                    function Init return My_Int;  -- == Added ==
                end P;
                use P;
                ...
                package I is new G(T1 => My_Int, Init => Init); 
                    -- "="(5) is declared in I (see below).   -- == Changed ==
                use I;

Is it correct?

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

From: Pascal Pignard
Sent: Wednesday, October 9, 2019 11:56 PM

[From private mail.]

I've read the AARM 202x draft 22 (text version).

Section 12.6 Formal Subprograms, I've found:
8.k/2           generic
                   type NT(<>) is new T with private;
                   -- Presume that T has the following primitive operation:
                   -- with procedure Bar (Obj : in T);
                package Gr ...

The comment: 
                  -- with procedure Bar (Obj : in T); would be better :
                   -- procedure Bar (Obj : in T); wouldn't it?

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

From: Randy Brukardt
Sent: Thursday, October 10, 2019  7:53 PM

[Sent to Tucker Taft.]

Both of these are original Ada 95 examples; I found both in the October 1994 
draft AARM as well as the current draft AARM.

I'm pretty sure the first comment is correct, as the second sentence of 
12.5.1(5/3) clearly applies. It's rather amazing that no one noticed this 
obvious mistake in the last 25 years.

For the second comment, I think that adding a formal subprogram would hide the 
operative parts of the example. Since it is incomplete already, I propose 
adding "..." to the formal part and to the instance in the example to show that 
there are other formal parameters without burdening the reader with the details.

Do you agree with both of these?

Assuming so, these are both AARM examples, so I propose to put this thread into
 AI12-0005-1 and then make the corrections (we do not follow a formal process 
for fixing the AARM unless there is a question that needs ARG input).

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

From: Tucker Taft
Sent: Thursday, October 10, 2019  8:45 PM

They both look like legitimate gripes to me.  The first is clearly a bug.  The 
second is simply complaining about the fact that there is no legitimate 
replacement for the ellipsis, which is interesting, but doesn't affect the 
fundamental point of the example, so is clearly less important (though more 
impressive as far as being noticed at all!).

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

From: Randy Brukardt
Sent: Friday, October 11, 2019  4:41 PM

...
> == As T1 is tagged, Formal needs "with private", as:
> type Formal is new T1 with private;

Yes, this is wrong. This is an original Ada 95 example, so this mistake has 
been in the AARM since at least October 1994 (I verified that in a draft from
that time). Amazing that no one has reported it.

...
> == As T1 is a private formal  type, so unknown, and therefore 
> T2 unknown as well (derived from T1), what initial value 
> could be given for T1_Obj and T2_Obj?
> Should be added a formal function? 

This is also an original Ada 95 example. Tucker Taft found it amazing that 
you even saw this situation, so you should pat yourself on the back for that.

However, correcting this as you suggest would somewhat hide the point of the 
example. Such a formal function is unrelated to the point and could only 
confuse a reader (and of course it makes the example longer). A better 
solution [given that the example already uses ellipses (...) in a number of 
places] is to place ellipses in the formal parameter list and in the 
instantiation to show that there are additional formal parameters without 
mentioning what they are.

P.S. Note that this is an instance of what Steve Baird calls "heat vision" 
(think Superman). When one reads old text, it sometimes explodes into flames.
Best to only read existing text if one has a need to understand it for some 
reason, lest your entire AARM turn to ashes. ;-)

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

From: Randy Brukardt
Sent: Friday, October 11, 2019  4:42 PM

I don't find this important at all, but I suppose you are right. Again, this 
is an example from Ada 2005, so it has been around for 12+ years and I don't 
think anyone has been confused. It's common to think of primitive operations 
of formal type much like implicit formal parameters - so the only reason to 
change this is that the parameter is the wrong type for such a formal 
parameter.

In any case, we're mostly interested in finding problems in *new* text (/4 
and /5 paragraphs), not in examples that have been around forever. It takes
time and energy to make these changes that probably would be better spent on
things that are really wrong and/or brand-new (such as the stray text you 
noted in Chapter 4).

Note that I don't mean that you should skip reporting problems that you happen
to notice, but more that you should try to avoid even reading for review old
text because any such reading inevitably leads to complaints.
(That's a sad fact about any document as large as the AARM; the same thing 
happens with the Janus/Ada documentation and the Claw documentation.)

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

From: Pascal Pignard
Sent: Tuesday, October 15, 2019  2:18 PM

[From private mail.]

I've read the AARM 202x draft 22 (text version).

Section 7.3 Private Types and Private Extensions, I've found:
7.w/2              procedure Bar (X : T1'Class) is
                   begin
                      Pkg.Foo (X); -- should call Foo #1 or an override thereof
                   end;

GNAT complains with: error: expected type "Ifc"

I propose the change:
         Pkg.Foo (Pkg.Ifc'Class(X)); -- should call Foo #1 or an override thereof

It compiles but I when I execute:
7.x/2           begin
                   Pkg.Foo (Pkg.Ifc'Class (P_Client.X));      -- should call Foo #2
                   Bar (T1'Class (P_Client.X));
                end P;
I got:
Foo #2
Foo #2

Is it correct?

In order to get Foo #1, I execute:
      X:T1;
   begin
      Pkg.Foo (Pkg.Ifc'Class(X));
      Bar (X);
   end P;
==
Foo #1
Foo #1


PS: I make a little change in the AARM example to avoid illegal statement.
See full source code:

with Ada.Text_IO;
procedure Test40 is

-- Section_7_3_Paragraph_7q

   package P is
      package Pkg is
         type Ifc is interface;
         procedure Foo (X : Ifc) is abstract;
      end Pkg;

      type Parent_1 is tagged null record;

      --  type T1 is new Parent_1 with private;
      type T1 is new Parent_1 and Pkg.Ifc with private; --@@ Change to avoid further illegal type declaration
   private
      type Parent_2 is new Parent_1 and Pkg.Ifc with null record;
      procedure Foo (X : Parent_2); -- Foo #1

      --                type T1 is new Parent_2 with null record; -- Illegal.
      type T1 is new Parent_2 with null record;
   end P;

      --@      with P;
   package P_Client is
      type T2 is new P.T1 and P.Pkg.Ifc with null record;
      procedure Foo (X : T2); -- Foo #2
      X : T2;
   end P_Client;

   package body P_Client is
      procedure Foo (X : T2) is
      begin
         Ada.Text_IO.Put_Line ("Foo #2");
      end Foo; -- Foo #2
   end P_Client;

      --@     with P_Client;
   package body P is
         --@        ...
      procedure Foo (X : Parent_2) is
      begin
         Ada.Text_IO.Put_Line ("Foo #1");
      end Foo; -- Foo #1

      procedure Bar (X : T1'Class) is
      begin
         Pkg.Foo (Pkg.Ifc'Class (X)); -- should call Foo #1 or an override thereof
      end Bar;

      X : T1;

   begin
      Pkg.Foo (Pkg.Ifc'Class (P_Client.X));      -- should call Foo #2
      Bar (T1'Class (P_Client.X));
      Pkg.Foo (Pkg.Ifc'Class (X));
      Bar (X);
   end P;

begin
   null;
end Test40;

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

From: Randy Brukardt
Sent: Thursday, November 14, 2019  9:29 PM

Eliminating the illegal line eliminates the point of the example, so I don't 
think it is particularly relevant what the rest of it does, or what it 
executes if it is modified to be legal.

> I propose the change:
>          Pkg.Foo (Pkg.Ifc'Class(X)); -- should call Foo #1 or an 
> override thereof

I worry this would be confusing for this example, but it can't be helped.
Part of the point is that identical calls could have different results 
depending on visibility, and I suppose this change makes it even more obvious. 

> It compiles but I when I execute:
> 7.x/2           begin
>                    Pkg.Foo (Pkg.Ifc'Class (P_Client.X));      
> -- should call Foo #2
>                    Bar (T1'Class (P_Client.X));
>                 end P;
> I got:
> Foo #2
> Foo #2
> 
> Is it correct?

Yes, once you make the interface visible, normal overriding occurs. This isn't 
very interesting.

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

From: Steve Baird
Sent: Saturday, November 23, 2019  1:22 PM

In some cases involving general access types and tagged types (thanks to
Randy for pointing out the latter case), evaluation of a membership test
    X in S
includes both
    a) determining whether the value of X is convertible to the type
       (as opposed to the subtype) of S
and
    b) having converted the value of S to the type of S, determining
       whether that converted value satisfies the subtype-specific
       requirements of S - constraints, null exclusions, and predicates.

At least that is how it should be defined. In particular, performing the
second step makes no sense if the outcome of the first step is
"no, this value is not convertible to the target basetype". So we
want some short-circuiting here.

Unfortunately, that is not what the current wording in RM 4.5.2 says.

I see two separate questions here:
    1) Strictly speaking, is the current wording broken? IMO, it is.
    2) If there is a problem, what (if anything) should be done about it?
    Would an AARM note suffice, or do we need normative RM wording, or
    something in between (e.g., a TBH note in the RM)?

Consider the following example:

    procedure P1 is
       -- The reader can decide whether "P" is short for "Procedure"
       -- or "Pathology".

       pragma Assertion_Policy (Check);

       type T1 is record
          Data : Integer := 0;
          Predicate_Test_Count : Natural := 0;
       end record;

       type T1_Ref is access all T1;

       Const : aliased constant T1 := (123, 0);
       Ref : access constant T1 := Const'Access;

       function Odd_Predicate (X : T1_Ref) return Boolean is
       begin
           X.Predicate_Test_Count := @ + 1;
           return X.Data mod 2 /= 0;
       end Odd_Predicate;

       subtype S1 is T1_Ref with Dynamic_Predicate =>
         Odd_Predicate (S1);
    begin
       if Ref in S1 then
          raise Program_Error;
       end if;
    end P1;

We don't want to see Odd_Predicate being invoked with
an access-to-constant value, but the current RM wording
seems to allow this possibility.

Randy points out that similar scenarios are possible
involving something like

    type Root is tagged null record;
    type Ext is new root with Data : Integer; end record;
    function Is_Even (Param : Ext) return Boolean is
       (Param.Data mod 2 = 0);
    subtype Even_Ext is Ext
      with Dynamic_Predicate => Is_Even (Even_Ext);

    function F (X : Root'Class) return Boolean is
       (X in Even_Ext);

    Flag : Boolean := F (Root'(null record));

where we don't want to see the function Is_Even being invoked
with an argument that doesn't even have a Data component.

My guess (and this is only a guess) is that clarifying the point
that we don't perform subtype-specific portions of a membership
test until after ascertaining that the basetype conversion would
succeed would have no impact on most compilers; this is probably
what they are doing already. This is just a matter of making
the RM wording match what was "obviously" intended.

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

From: Tucker Taft
Sent: Sunday, November 24, 2019  9:39 AM

I would say an AARM "to-be-honest" note would be adequate.  I presume in the 
long run we would think about ways to incorporate the various TBH notes 
directly into the normative text, but in cases like this, it seems better to 
avoid reworking the normative wording (but I could be convinced otherwise!).

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

From: Randy Brukardt
Sent: Sunday, November 24, 2019   6:14 PM

I agree. I doubt any implementer is likely to make a mistake here, mainly 
because evaluating a predicate is in general more expensive than checking a 
tag (and certainly more expensive than compile-time checks). So simply having 
a note so that anyone that wonders is aware that the order might matter seems 
like enough.

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

From: Steve Baird
Sent: Monday, November 25, 2019  12:16 PM

Sounds good to me.

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

From: Randy Brukardt
Sent: Monday, November 25, 2019   2:43 PM

Do you want a separate AI, or is it OK to just file this thread into
AI12-0005-1 (the "fixes for the AARM" AI, which is an empty AI that just holds 
AARM fixes for the record - never to be voted on by the ARG)?

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

From: Steve Baird
Sent: Monday, November 25, 2019   6:26 PM

Fine with me if we make adding this TBH note an editorial fix (i.e., the 
AI12-0005-1 alternative).

If anyone wants to discuss this, speak up and we'll turn it into its own AI.

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

From: Pat Rogers
Sent: Wednesday, December 4, 2019  12:13 PM

In 6.1.1, para 27.j/3, we have a paragraph starting with

"In this example, the compiler cannot know the value of I when the subprogram 
returns (since the subprogram execution can change it),"

that ends with

"which eliminates anything that could change at during execution."


So the word "at" is extraneous.

It may be removed already in the latest copy but I suspect not.


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

From: Randy Brukardt
Sent: Friday, December 6, 2019  10:32 PM

This appears in the Ada 2012 version of the AARM, so it's not on anyone's 
radar for fixing. I'll put this into the "Comments on the AARM" AI 
(AI12-0005-1), which is just a mail collection. The error is fixed in the 
working copy of the AARM.

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

From: Tucker Taft
Sent: Friday, February 28, 2020  2:09 PM

[A response to another thread, we only include the relevant part here,
the full thread can be found in AC-00326 - Editor.]

A collection is an abstract concept, and it represents all of the objects 
created by an allocator for a given access type (or any of its descendants).
There is only one collection per access type, even if there are multiple 
subpools. Unfortunately, the AARM implementation note 7.6.1(20.e.3) uses 
the term "collection" in a different sense, probably meant to convey a 
linked list of objects that hangs off a header associated with the access 
type, so the allocated objects that still exist can all be found and 
finalized at the end of the scope of the access type.

...

The problem, as mentioned above, is that this AARM note is not using the 
term "collection" properly, but rather using it as a short-hand for 
something like a linked list of allocated objects.  The last 
sentence of that note currently says:

   "This is expected to ease implementation, as the objects will only need to 
   belong to the subpool and not also to the collection." 

Instead, it should probably say:

   "This is expected to ease implementation, as the remaining un-deallocated 
   objects will only need to be accessible at run time from the subpool header 
   rather than from the overall access type collection header."

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

!topic Incorrect references in index to Bounded_IO and Unbounded_IO
!reference Ada 202x 2012 2005 RM index
!from Manuel Gómez Rojo 20-02-28
!keywords inconsistent naming index Wide_Text_IO Wide_Wide_Text_IO Bounded_IO Unbounded_IO
!discussion

The following package names are referenced in the index:

 Ada.Wide_Text_IO.Bounded_IO   A.11(4/3)
 Ada.Wide_Text_IO.Unbounded_IO   A.11(5/3)
 
 Ada.Wide_Wide_Text_IO.Bounded_IO   A.11(4/3)
 Ada.Wide_Wide_Text_IO.Unbounded_IO   A.11(5/3)


But in A.11 the package names repeat Wide(_Wide) at the 
grandchildren level:

 4/3
 The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as[...]
 
 5/3
 The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as[...]

Given that the index is not normative, it should be amended in this way:

 Ada.Wide_Text_IO.{Wide_}Bounded_IO   A.11(4/3)
 Ada.Wide_Text_IO.{Wide_}Unbounded_IO   A.11(5/3)
 
 Ada.Wide_Wide_Text_IO.{Wide_Wide_}Bounded_IO   A.11(4/3)
 Ada.Wide_Wide_Text_IO.{Wide_Wide_}Unbounded_IO   A.11(5/3)

Specific index of library units in A is already consistent.

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

From: Randy Brukardt
Sent: Monday, March 2, 2020  10:44 PM

Wide_Wide_ nonsense strikes again! It would have been nice if Ada was 
consistent about whether or not to repeat Wide_Wide_, but it isn't. I'm
looking forward to Wide_Wide_Wide_Strings and associated operations. ;-)

Thanks for finding and reporting this; we can't fix bugs we don't know 
about.

Since the index is not normative, this just gets stuck in the AI of 
non-normative corrections (AI12-0005-1) and the correction gets made to 
the master copy. So it will be made the next time that an RM/AARM draft is 
posted.

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

From: Arnaud Charlet
Sent: Wednesday, March 11, 2020  12:04 PM

See http://www.ada-auth.org/standards/2xrm/html/RM-D-13.html

The first paragraph contains a spurious "}" that should be removed.

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

Note from ARG Meeting #62C.

The list of representation aspects found from AARM 13.1(8.f-8.kk) is 
incomplete. That's in part because the list is of "representation items" 
rather than "representation aspects", and an aspect_specification is NOT
a representation item. Thus, representation aspects that are not 
specifiable with a representation item (like Default_Value) are not in 
this list.

In addition, the Annex D representation items are missing. Note that this
list, unlike the rest of the AARM, includes all of the obsolescent
representation items (presumably to make a more complete list).

This is helpful that we'd like, so we add the missing items to the
main lists, and add the remaining aspects to yet another set of
lists.

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

topic Empty pragraph scrambles HTML
!reference Ada 202x AARM 2.2(3.a/2)
!from Christoph Grein 20-06-22
!discussion

In draft 22 PDF version (annotated RM), there is an empty paragraph 3.a/2.
In the HTML version draft 25, this paragraph is overwritten by the next 
para 4/2, making the number an unreadable mess.

I guess the culprit is the empty 

<div class="Annotations"></div>
section, which does not produce a new line.

Best just remove 3.a/2

This is already in the Ada 2012 TC1 AARM HTML version.

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

From: Randy Brukardt
Sent: Friday, July  3, 2020  10:39 PM

This paragraph is already marked as deleted (as you can see in the "all 
changes" version), so that's not the answer.

(After 3 hours of debugging and reorganizing...) As I suspected, there is 
a bug in the formatting tool. The code to determine whether or not to show 
a paragraph number and other start information depends (of course) on the 
formatting mode. But it doesn't (for the most part) take into account the 
possibility of not showing old deletions in the Show_Changes mode. The AARM 
is generated in that mode in order to only show changes from Ada 2012. There
was a routine to do that properly, but it was only called when there are no 
paragraph numbers (this suggests that I fixed this problem for RR's 
documentation but never noticed that the same problem would occur for the 
RM).

There is about 200 paragraphs in the AARM affected. I'm surprised that you 
didn't complain about the mess of overlapping and reference-only paragraphs 
in 4.6, for instance. That was a way worse mess than the single paragraph 
in 2.2.

This change does eliminate the references to old deleted paragraphs, but 
given that this AARM version is supposed to be showing changes from Ada 2012, 
deletions that occurred in Ada 2005 and the Ada 95 Corrigendum aren't really 
relevant. Argubly, all of the references to older AIs should be suppressed, 
but that would require having the tool know the correspondence between 
versions and AIs.

In any case, this should all look much better in draft 26.

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

From: Tucker Taft
Sent: Monday, July 27, 2020  8:24 AM

We mention in RM 4.3 an incompatibility in resolving aggregates due to types 
with an Aggregate aspect now being considered as well.  We indicate the 
incompatibility will be rare.  Alas, it turns out the overloaded "Append" 
procedure in Containers.Vectors creates the exact situation where the 
incompatibility shows up, because it is overloaded with one version having 
the Element_Type and one having Vector as its second parameter.  So any use of 
Append with the second parameter being an aggregate is now ambiguous if the 
Element_Type is a record or array type (or any type that allows an aggregate).
The Append_One function (which is new, I believe), can be used to resolve the 
ambiguity in favor of appending an element. 

Interestingly, this same ambiguity has existed forever with arrays of 
records/arrays when using the "&" operator.  So now Vectors are even more 
like arrays! ;-)

In any case, I believe we should remove the claim that this is "rare" in the 
incompatibility section of RM 4.3, and perhaps mention it elsewhere (e.g. in 
Vectors and Doubly_Linked_Lists), where we could suggest using Append_One 
(see below) to resolve the ambiguity in favor of appending an element.

One more serious issue is that the Aggregate aspect in Doubly_Linked_Lists 
points at the Append procedure for Add_Unnamed, and I think in fact we need 
to introduce a new procedure Append_One as was done for Vectors, since Append
actually takes three parameters. [Editor's note: This problem was previously
raised and is addressed in AI12-0391-1.]

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

From: Tucker Taft
Sent: Monday, July 27, 2020  8:34 AM

> ... The Append_One function (which is new, I believe), can be used to 
> resolve the ambiguity in favor of appending an element.

Make that, the Append_One *procedure* ...

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

From: Tucker Taft
Sent: Tuesday, July 28, 2020  12:22 PM

If we think this incompatibility could be a significant burden, we could, at 
least initially, distinguish the Name Resolution rules for aggregates using 
"[...]" from those using "(...)".  At some future revision we could consider 
taking the "hit" to make "(...)" use the same rule.  This might ease 
transition to Ada 202X.

For what it is worth, this incompatibility (along with the addition of the 
"Empty" functions in Container packages) has caused some headaches at AdaCore
over the last week or two.

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

From: Arnaud Charlet
Sent: Wednesday, July 29, 2020  2:45 AM

> If we think this incompatibility could be a significant burden, we could, at 
> least initially, distinguish the Name Resolution rules for aggregates using 
> "[...]" from those using "(...)".  At some future revision we could consider
> taking the "hit" to make "(...)" use the same rule.  This might ease 
> transition to Ada 202X.

No, I don't think it would be a good idea to go half way there.

> For what it is worth, this incompatibility (along with the addition of the 
> "Empty" functions in Container packages) has caused some headaches at 
> AdaCore over the last week or two.

Yes, it did (and still does) although I believe part of it should be 
alleviated (some Ada 2012 code got impacted that shouldn't have been).

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

From: Randy Brukardt
Sent: Wednesday, September 2, 2020  12:59 AM

> We mention in RM 4.3 an incompatibility in resolving aggregates due to 
> types with an Aggregate aspect now being considered as well.  We 
> indicate the incompatibility will be rare.  Alas, it turns out the 
> overloaded "Append" procedure in Containers.Vectors creates the exact 
> situation where the incompatibility shows up, because it is overloaded 
> with one version having the Element_Type and one having Vector as its 
> second parameter.  So any use of Append with the second parameter 
> being an aggregate is now ambiguous if the Element_Type is a record or 
> array type (or any type that allows an aggregate).  The Append_One 
> function (which is new, I believe), can be used to resolve the 
> ambiguity in favor of appending an element.

For what it's worth, the same ambiguity could happen for Insert, Prepend, 
and "&"; all of these take a Vector or an Element as a parameter. But none 
of these happen to have an Append_One to fix the problem.

> Interestingly, this same ambiguity has existed forever with arrays of 
> records/arrays when using the "&" operator.  So now Vectors are even 
> more like arrays! ;-)

Yup.
 
> In any case, I believe we should remove the claim that this is "rare" 
> in the incompatibility section of RM 4.3, and perhaps mention it 
> elsewhere (e.g. in Vectors and Doubly_Linked_Lists), where we could 
> suggest using Append_One (see below) to resolve the ambiguity in favor 
> of appending an element.

Lists don't have these overloaded operations, so no ambiguity problem occurs 
for lists. This is solely a problem for vectors. As noted above, the 
suggestion doesn't help unless you happen to be using Append (rather than 
Insert or Prepend or "&"), so the suggestion isn't very general. It would be 
better to simply suggest qualification, but that's already what the 
incompatibility note says.

I still think the incompatibility is unlikely for most types, but obviously 
Vectors isn't most types.

So I suggest replacing the last three sentences in the AARM note 4.3(6.l/5):

   This can be incompatible in unlikely cases, where overloading of a container 
   or private type with a type that was previously allowed in aggregates makes 
   an existing call ambiguous. (For an example, replace type Lim in the example 
   given above under Incompatibilities With Ada 95 with a Vector from an instance 
   of Ada.Containers.Vector. The call of P in that case will be illegal in Ada 
   202x and legal in Ada 2012.) This can easily be fixed by qualifying the 
   aggregate with the correct type. 

with:

   This can be incompatible in usually unlikely cases, where overloading of a 
   container or private type with a type that was previously allowed in 
   aggregates makes an existing call ambiguous. Unfortunately, Ada.Containers.Vectors
   has a number of such overloadings for Insert, Append, Prepend, and "&", so
   the problem may appear for any element type of a Vector that allows aggregates.
   For instance, if My_Vector is an instance of Ada.Containers.Vectors with an 
   element type of Not_Lim as defined above, and V is an object of My_Vector.Vector, 
   then My_Vector.Append (V, (Comp => 123)); will be illegal in Ada 
   202x and legal in Ada 2012. This can easily be fixed by qualifying the 
   aggregate with the correct type.  


A couple of points about this:
(1) It makes sense to replace the example by one that is likely to occur.
(2) It seems necessary to say that the incompatibility is usually unlikely; 
    otherwise, we'd have no justification for introducing it.
(3) Mentioning Vectors here explains the type that is known to have a problem, 
    and the one most likely for a user to run into.

Finally, we probably ought to mention this in A.18.2 as well. So add a new 
Incompatibility AARM note at the end of A.18.2:

   Vector objects now support aggregates. This introduces a potential incompatibility 
   for overloaded routines, including the Insert, Append, Prepend, and "&" operations
   defined in this package. If the Element_Type of the vector is a type that allows
   aggregates (such as a record type), then calls to the operations above with an
   aggregate element will become ambiguous in Ada 202x, while they would have been
   legal in Ada 2012. This can be fixed by qualifying the aggregate with the element 
   type.  

Since these are all AARM changes, these don't get an AI or otherwise put on 
the agenda, so don't hold any comments.

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

!topic When is a big real valid?
!reference Ada 202x RM A.5.7(4/5) Draft 25
!from Christoph Grein 20-06-04
!discussion

There is no statement about when a big real is valid. (23/5) says "The other 
functions have their usual mathematical meanings." I do not know the usual 
mathematical meaning of validity of a number.

[BTW: Is there a general definition what a number is? Think of John Horton 
Conway's definition of numbers starting with the empty set.]

I can guess that a big real is valid if both numerator ad denominator are 
valid big integers and the denominator is not 0. Is guessing another step 
in the direction of Ada++?  ;-)

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

!topic Big Integers typo
!reference Ada 202x RM A.5.6(9/5) Draft 25
!from Christoph Grein 20-06-05
!discussion

subtype Big_Natural is Big_Integer
      with Dynamic_Predicate => (if Is_Valid (Big_Natural) then Big_Natural [=>]{>=} 0),
           Predicate_Failure => (raise Constraint_Error);

BTW: As for big reals, it's not defined when a big integer is valid.

Is validity defined implicitly via the operations with a result of 
Valid_Big_Integer? I.e. a big integer is only valid if it is constructed 
with any of these constructors?

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

From: Randy Brukardt
Sent: Wednesday, June 10, 2020  6:59 PM

>	subtype Big_Natural is Big_Integer
>	      with Dynamic_Predicate => (if Is_Valid (Big_Natural) then
Big_Natural [=>]{>=} 0),
>	           Predicate_Failure => (raise Constraint_Error);

I fixed the typo in the working RM draft.

>	BTW: As for big reals, it's not defined when a big integer is valid.
>
>	Is validity defined implicitly via the operations with a result of 
>Valid_Big_Integer? I.e. a big integer is only valid if it is 
>constructed with any of these constructors?

The validity of a default-initialized Big_Integer or Big_Real is intentionally 
left undefined. Some SPARK people said they needed it that way to use their 
existing uninitialized object analysis.

Honestly, why that is necessary escapes me. The original Big_Integer and 
Big_Real definitions had a
   Default_Initial_Condition => not Is_Valid (Big_Integer); which neatly 
defines the validity for fully dynamic (that is, Ada) implementations. And 
an implementation with static checks for uninitialized objects could ignore 
that specification (since Is_Valid is already defined as intrinsic so that an
implementation could replace it completely with static checks).

Anyway, given the need for compromise it's left undefined.

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

Summary of private discussion between Randy Brukardt, Steve Baird, and Tucker 
Taft:

Steve: For Big_Integers, we have an AARM note
    This means that the elaboration of
       Default_Initialized_Object : Valid_Big_Integer;
    is required to propagate Program_Error.

There is an analogous note for Big_Reals.

What does that follow from?

Tucker: The current situation is closely tied to what works for SPARK in 
trying to map these directly to "mathematical" integers/rationals, so we need
to be sure we don't end up breaking that mapping.

One of the goals was to catch use of uninitialized variables.  If Is_Valid is 
true by default, then you have to define what is the default value of a 
Big_Real.  I don't think we wanted to do that.  So yes, Is_Valid is presumably 
False by default, though there is no language-provided way to create an 
uninitialized value except by declaring and not initializing a variable, so I 
don't think you have to define what makes a Big_Real valid, other than being 
initialized.

Steve: For static analysis purposes, all that is really required is that a 
default initialized big number (integer or real) is not known to be valid. It 
doesn't have to be known to not be valid.

So it might be ok to leave things as is (i.e., Is_Valid is unspecified after 
default initialization), but then we ought to fix those AARM notes I mentioned
that state otherwise.

Randy: At a minimum, something like "the result Is_Valid on a 
default-initialized object of type Big_Real is unspecified" would seem to be 
necessary. I suppose we could justify *that* as an AARM note (saying 
something is unspecified doesn't really require being said explicitly!)

Tucker: So we might change the current AARM note to say:

  The result of Is_Valid on a default-initialized object of type Big_Real is
  unspecified, analogous to the value of a Valid attribute_reference applied
  to a default-initialized object of a real type (see 13.9.2).  The 
  language-provided functions in the Big_Reals package only return values for 
  which Is_Valid is certain to be True.

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

!topic Any two actions of the same logical thread of control[;] are sequential,...
!reference Ada 202x AARM9.10(13.a/5)
!from Christoph Grein 20-08-29

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

From: Pascal Pignard
Sent: Wednesday, September 2, 2020 11:01 AM

Here is one typo: a space is missing before "Declaring...":

6.4.1 Parameter Associations

19.k/5      {AI12-0074-1} {AI12-0159-1} {AI12-0377-1} {AI12-0378-1}
            Corrigendum: Added rules to ensure that the value passed into an
            out parameter for scalar types is well-defined in the case of a
            view conversion. The new rules can be incompatible. For a view
            conversion to an unrelated type with the Default_Value aspect
            specified, the aspect is new in Ada 2012 so it should be unlikely
            to occur in existing code.      Declaring and passing a temporary rather
            than a view conversion will eliminate the problem.

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

!topic function "@key{xor}" (Left, Right : Set) return Set

!reference Ada 202x RM A.18.8(36/2)
!from Christoph Grein 07-09-29
!discussion HTML version - Text within the string quotes is wrong, should be as in Ada 2012 TC1:
"<b>xor</b>"
(Must have been introduced with all these Pre and Post.)

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

From: Randy Brukardt
Sent: Wednesday, September 9, 2020  2:47 PM

> (Must have been introduced with all these Pre and Post.)

Nope. I noticed some "missing" indexing and put in the appropriate commands. 
When I was almost done with Draft 26, I happened to notice that the index 
entries were @key{xor}. The bolding command doesn't get interpreted in the 
index commands; the commands had been left out on purpose. I removed the 
indexing, but figured no one would notice errors in the index so I didn't 
regenerate the draft (which would have required redoing several hours of 
work) - it certainly would have been fixed the next time.
 
Unfortunately, the failure also appears in the body of the RM. Had I noticed 
that, I would have started over generating the draft (and spent quite a bit 
of time swearing loudly :-).
 
Anyway, it was fixed before the draft was even fully posted. It certainly 
will be fixed next time.
 
P.S. You're already the second person to complain, and I doubt that you will 
be the last. It appears in all of the operators of A.18.8 and A.18.9, not just
the one mentioned. (Except one, which was a bug-within-the-bug.)

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

!topic Inheritance of literal aspect
!reference Ada 202x AARM 4.2.1(6.a/5-6.e/5)
!from Christoph Grein 28-09-20
!discussion :
Would the initial value of Pkg2.X be (1,1) if T2 were defined like so:
   type T2 is new T1 with Integer_Literal => I_L;
according to 13.1(15.1/3)? If so, I propose to state that. (I had a hard time 
finding all the relevant paras, and probably missed some important ones.)

BTW a typo: (6.e/5) The initial value of Pkg{2}.X is (0,0), not (1,1).

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

!topic We also allow aspect_specifications on all kinds of bodies, but 
       {there} are no language-defined aspects...
!reference Ada 202x AARM 13.1.1(4.c/5)
!from Christoph Grein 28-09-20 

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

[From the AARM Review of Gary Dismukes (October 2020) - Editor.]

1. General
----------

In AARM 2.bb.8/3, change period to a comma:

2.bb.8/3 Wording Changes from Ada 2005[.]{,}

1.1.2 (Structure)
---------------

Missing 's':

39.a.1/5
Discussion: Names used in examples refer either to language-defined entities 
or to entities declared in other Example{s} in this Standard.

2.3 (Identifiers)
-----------------

AARM 8.f/5, last sentence:

Identifiers that may be interpreted differently by different compilers [is] 
{are} a safety and security hazard, so we no longer allow them.

3.1 (Declarations)
------------------

In AARM 7.e/5, replace a hyphen with a space: "compile-time" => "compile time"

3.2.4 (Predicates)
------------------

Minor edits in AARM 29.a/4:

Discussion: This is the usual way around the contract model; this applies even 
in instance bodies. Note that errors in instance specifications will be 
detected at compile[-]{ }time by the "re[-]check" of the specification, {and} 
only errors in the body should raise Program_Error.

[Editor's note: Rather than adding "and", the immediately preceding comma
should be a semicolon.]

In AARM 31.a.1/5, add a hyphen: "parameter{-}[ ]passing cases".

3.3 (Objects and Named Numbers)
-------------------------------

In AARM 26.o/5, last sentence, replace "rename" with "renaming_declaration"
(or at least "renaming") in two places.

3.3.1 (Object Declarations)
---------------------------

In the third sentence of AARM 33.n/5, add "will" for clarity:

"... In most cases, this will have no visible effect, or {will} even fix bugs."

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

[From the AARM Review of Jeff Cousins (October 2020) - Editor.]

13.1 (8.mm/5) Typo: ad{d}ition

13.1 (29.q/3) Typo: a[n] representation
	 
13.1.1 (14.a/4) I would insert a comma after “for instance)”.

13.1.1 (38.e/5) Reads strangely, maybe insert “the” before “statically”.

13.3 (52.a.1/5) Typo: and{ }allows (replicated in Annex M.3).

13.12.1 (8.a/2) Typo: exist{s} (twice).

13.13.1 (37.a/5) Typo: in orde{r}

13.11 (17.b) The standard pool can be referred to under AI12-0003, see
13.11.3 (3.1/4).

[Editor's reply: This is a direct echo of the preceding normative text, and 
it is the text for Annex M.3 (it's not intended to provide any information 
itself).

Note that the name "Standard" as defined in AI12-0003-1 does not "provide a
user-accessible name for the standard pool type(s)". It provides a way to 
force use of the Standard way of selecting a pool, which may or may not have 
a name.

I realize that this is splitting hairs in some sense, but that is the reason 
this text wasn't changed. We could add a note to explain this more here, but
M.3 would not be changed in that scenario.
End Editor's Reply.]

Could 13.11 (17.b) have an AARM note on the lines of “Although there is no 
language-defined user-accessible name for the standard pool type(s), the use
of a standard pool may be indicated using ...” ?

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

[From the AARM Review of Brad Moore (October 2020) - Editor.]

7.5 Limited Types
-----------------

In AARM 2.a.1/2, a comma should have been a semicolon.

2.a.1/2
"Rules about progenitor interfaces can be found in 3.9.4[,]{;} specifically, a 
nonlimited interface can appear only on a nonlimited type."

7.6 Assignment and Finalization
-------------------------------

In AARM 17.l/3 bad verb tense, chose vs. choose

17.l/3
"However, we expect that most Ada implementations will determine this 
property at compile-time using some assume-the-worst algorithm in order
 to [chose]{choose} the appropriate method to implement a given call or aggregate. "

In AARM 18.b/3, extra "a" should be deleted

18.b/3
"This is important so that the programmer can count on [a] stricter semantics 
for limited controlled types."

7.6.1 Completion and Finalization
----------------------------------

In AARM 20.e/5, missing a "than"

20.e/5
"That is, they only need to belong to a single list, rather {than} two."

8.1 Declarative Region
----------------------

In AARM 18.u/5, should probably mention that we also added 
access_definition and iterated_element_association to the 
list of constructs with declarative regions.
 
18.u/5
"Added {access_definition, }iterated_component_association{, 
iterated_element_association,} and
declare_expression to the rapidly expanding list of 
constructs that have a declarative region."

[Editor's note: access_definition was added by the Corrigendum, and
is already mentioned in 18.r/4.]

8.3 Visibility
--------------

In AARM 12.g/2, incorrect verb plurality, are should be is, since "effect" is singular.
 Alternatively, leave as "are", but change "effect" to "effects"

12.g/2
"If we had used such a rule, any successful calls would be confusing; and 
the fact that there [are]{is} no Beaujolais-like effect to worry about"

8.5.1 Object Renaming Declarations
----------------------------------

In AARM 4.a/5, each bullet defines a rule, so rule should be plural, and the
 sentence updated to reflect this. Also there is a "which" that should be a "that".

4.a/5
"The bullets are [an] assume-the-worst rule{s that} [which] prevent[s] trouble 
in two obscure cases:"

9.4 Protected Units and Protected Objects
-----------------------------------------

In AARM 35.k/4, misspelling of "convenient".

35.k/4
"Corrigendum: Null procedures and expression functions are allowed in protected
bodies. We consider this an omission, as there is no reason why the
[convinient]{convenient} shorthand notations should not be allowed in
this context."

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

[From the AARM Review of BOb Duff (October 2020) - Editor.]

A.4.5(81.a/5): "as" --> "because"?

A.5.2(41.a/5):

Discussion: {AI12-0144-1} In this rule, “consecutive” means at least 
that there are no intervening explicit calls involving the same 
generator. This restricts the rule to only applying to cases where 
just the Random function changes the generator. We don't mean to 
impose a requirement if there are intervening calls to Reset, to 
Random with the same generator but a different result range, or any 
other case that would affect the sequence of values returned. 
Operations which use the

"which" --> "that"

resulting random values (for instance, to store them somewhere) are 
not considered in determining if calls are consecutive.

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

[From the AARM Review of Tullio Vardangea (October 2020) - Editor.]

D (22.1/5): While starting a protected action on a protected object when the 
FIFO_Spinning admission policy is in effect, a task inherits the ceiling 
priority of the protected object (see 9.5, D.3, and D.4.1).
	should mention: on a multiprocessor

Editor's reply:
  My understanding is that this always true. It's not visible on a 
  monoprocessor -- starting a protected action isn't divisible on a 
  monoprocessor (one cannot tell what the active priority is during 
  the instant when a protected action is started). But there doesn't
  seem to be any reason to complicate the general rules with details like 
  that.

  So I suggest mentioning in the following AARM note that this rule only 
  matters when tasks on a different processor from the protected object P 
  might start an action on P. And in particular, it doesn't matter on a 
  monoprocessor.

D.4.1 (7/5) 
Busy-waiting as an access control policy only makes sense on a multiprocessor. 
The text does not say it, but it should, I think.

Editor's reply:
  I don't see any problem, as the text is clear that it only applies IF 
  busy-waiting is used. This again is a place where we don't want clutter the
  standard with irrelevant facts. It probably makes sense to mention that 
  busy-waiting only makes sense on a multiprocessor in an AARM note (as was
  done previously).

D.16 (15/5)
To my reading (but I may be too tired at this point), this clause prescribes 
that a task on processor X cannot call a protected object on processor Y (for
X different from Y), but then I do not understand what busy-waiting is for. 
The former prescription is perfectly sound when each processor has its own 
statically-assigned set of tasks and protected objects and runs then as if 
it was a single-processor system (aka fully-partitioned system). But in that
case the admission policy surely is not spinning, which is needed when a 
calling task that cannot proceed does not want to relinquish its local processor.

Editor's reply:
  My understanding of this rule is that for a protected object *that is 
  assigned a processor*, it cannot be called from a task that might run on
  some other processor.

  However, a protected object that is NOT assigned a processor has no such 
  limitation. Such a protected object would presumably use busy-waiting and
  might need an admission policy.

  AI12-0281-1 is very clear that assigning a PO to a CPU is intended to remove 
  any spin-locking overhead. That's the purpose behind allowing such 
  specification in the first place.

  I added an AARM note to explain the intent.

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

[From the AARM Review of Jean-Pierre Rosen (October 2020) - Editor.]

A.18 (2.a/5):
   if the cursor objects designated dif{f}erent elements

-----
A.18(5.v/2):
   All this means {that,} if the containers are written in Ada{,} [is
   that ]checks should not be suppressed or removed

------
A.18.2 (6.b/5)
   it still includes the blocking [a]{e}ffects of the actual
   parameters

-----
A.18.2 (7.a/5)
   Therefore, we require that operations that only operate on the
   container implementation b[y]{e} nonblocking

-----
A.18.2(254.a/3)
   Note that such an implementation would [be ]require care,

-----
A.18.3(70.c/5)
   by multiple operations (sequenti[u]ally or in parallel)

[Editor's note: This spelling error occurs in a number of subclauses;
fixed them all.]

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

[From the AARM Review of Tucker Taft (October 2020) - Editor.]

--------
3.10.2

Two typos:

41.bb/5:  Correction: Tightened the cases where an explicitly 
aliased parameter has special accessibility, to avoid needing 
to pass the required dynamic accessibility to functions that 
have explicitly ali{a}sed parameters. The changes affect[s] 
programs that use the dynamic accessibility of an explicitly 
aliased parameter within a return statement of a function 
(typically using anonymous access types). This can mean that 
a program that would have been legal and worked in Ada 2012 
as defined would raise Program_Error or be rejected in Ada 
202x. One such example is: 

Another typo:

41.ee/5:  At (2), there is a check that the dynamic 
accessibility level of B is not deeper than the master of the 
call for F2 (which is defined to be the master of the call 
for F1). In Ada 2012, since the reference is inside of a 
return statement, the dynamic accessibility of A.Comp'Access 
is the master of the call for F1 - meaning the check at (2) 
should pass. In Ada 202x, the [the] dynamic accessibility of 
A.Comp'Access is local for for F1 - meaning the check at (2) 
should fail and raise Program_Error.

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

[From the AARM Review of John Barnes (October 2020) - Editor.]

10.1  9.d         Please move the commas outside the quotes. As in 10.1  9.

[Editor's reply: 10.1 only goes to 4.d. There is a period inside of quotes 
in 4.d. Ahhhh, you meant 10.1.1(9.d). These will just be fixed, as they don't 
change any meaning.]

11.4.2  23.e/5    The last part of this seems garbled at first sight. Some 
such requirements etc. Maybe the trouble is simply that Suppressed should 
be suppressed.

11.5  31.m/5 and n/5  It would be clearer if m/5 said The various assertion
checks for language defined packages such as Calendar are new.  It then 
becomes clearer (in n/5) that also adding Program_Error_Check_and 
Tasking_Check covers the lot. 

11.6  7.g/3 At first sight I thought that AI05-0299-1 would explain but that 
is just about using subclause instead of clause. It is about the fact that 
in Ada 83, the clause Suppressing Checks was numbered 11.7.  It should be 
changed to read something like 

We moved subclause "Suppressing Checks" which was numbered 11.7 from after 
11.6 to before 11.6 etc.

12.3  7.a/5         Duplicate a in "...apply to a a generic..."

12.3  11.aa/3     "... every Semantic Item is sucked in by one of those."  
Sounds vulgar. Perhaps "is covered" rather than "is sucked in".

[Editor's note: I used "is included indirectly" as that is the meaning.
It's a bit weird to be wordsmithing Ada 9x notes, given they've already
been around 25+ years.]

12.3  18.g/5       "an generic instantiation" should be "a generic instantiation".

12.5.1  23.a/2    I was surprised to read that Constrained is now considered obsolete.
I see that it is in J. Maybe I need to update my book.
I always find the phrase considered obsolete rather odd. Is the wretched thing
obsolete or not? Do we always say "considered obsolete" rather than just
"obsolete"? No. I searched for considered obsolete and this was the only instance
found by Acrobat. So perhaps here we should just say obsolete.

[Editor's note: The proper term is "obsolescent", there is only one other use
of "obsolete" outside of Annex J. "Considered" is probably a noise word, but it
is used often in the AARM, so changing for just that probably isn't worthwhile.
But since we're changing this paragraph anyway to get rid of "obsolete", might
as well get rid of "considered" too.]

12.6  8.j/5         I would insert "as" so it reads "... to be class-wide as 
in the following unusual case."

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

From: Pascal Pignard
Sent: Saturday, January 2, 2021  3:38 AM (privately to the editor)

Hello, here is a very minor typo: double period at the end of some paragraphs:

3.2 Types and Subtypes
10.d/2      {AI95-00442-01} The set of limited types does not form a class
            (since nonlimited types can inherit from limited interfaces), but
            the set of nonlimited types does. The set of tagged record types
            and the set of tagged private types do not form a class (because
            each of them can be extended to create a type of the other
            category); that implies that the set of record types and the set
            of private types also do not form a class (even though untagged
            record types and untagged private types do form a class). In all
            of these cases, we can talk about the category of the type; for
            instance, we can talk about the "category of limited types"..

3.9 Tagged Types and Type Extensions
26.b/3      Implementation Advice: Tags.Internal_Tag should return the tag of
            a type, if one exists, whose innermost master is a master of the
            point of the function call..

4.2 Literals
4/5 {AI12-0325-1} {AI12-0373-1} The expected type for a primary that is a 
string_literal shall be a single string type or a type with a specified 
String_Literal aspect (see 4.2.1). In either case, the string_literal is 
interpreted to be of its expected type. If the expected type of an integer 
literal is a type with a specified Integer_Literal aspect (see 4.2.1), the 
literal is interpreted to be of its expected type; otherwise it is interpreted 
to be of type universal_integer. If the expected type of a real literal is a 
type with a specified Real_Literal aspect (see 4.2.1), it is interpreted to be
of its expected type; otherwise, it is interpreted to be of type 
universal_real..

11.5 Suppressing Checks
1/2 {AI95-00224-01} Checking pragmas give instructions to an implementation on 
handling language-defined checks. A pragma Suppress gives permission to an 
implementation to omit certain language-defined checks, while a pragma 
Unsuppress revokes the permission to omit checks..

13.7.1 The Package System.Storage_Elements
11.c/2      Implementation defined: The range of
            Storage_Elements.Storage_Offset, the modulus of
            Storage_Elements.Storage_Element, and the declaration of
            Storage_Elements.Integer_Address..

A.1 The Package Standard
56.k/2      {8652/0028} {AI95-00145-01} Corrigendum: Corrected the parameter
            type for the Boolean operators declared in Standard..

A.4.4 Bounded-Length String Handling
101/1       {8652/0049} {AI95-00128-01} {AI95-00238-01} Returns the slice at
            positions Low through High in the string represented by Source;
            propagates Index_Error if Low > Length(Source)+1 or High >
            Length(Source). The bounds of the returned string are Low and
            High..

A.18.20 The Generic Package Containers.Bounded_Doubly_Linked_Lists
11/5        Returns a list whose elements have the same values as the elements
            of Source..

C.5 Aspect Discard_Names
5/4 {AI12-0072-1} The local_name (if present) shall denote an entity with 
runtime name text. The pragma specifies that the aspect Discard_Names for the
type or exception has the value True. Without a local_name, the pragma
specifies that all entities with runtime name text declared after the pragma,
within the same declarative region have the value True for aspect
Discard_Names. Alternatively, the pragma can be used as a configuration
pragma. If the configuration pragma Discard_Names applies to a compilation
unit, all entities with runtime name text declared in the compilation unit
have the value True for the aspect Discard_Names..

F.3.2 Edited Output Generation
46  4.  Any other Character is replaced by the space character..

M.3 Implementation Advice
12/3   * Tags.Internal_Tag should return the tag of a type, if one exists,
        whose innermost master is a master of the point of the function call..
        See 3.9(26.1/3).

I wish you and your family the best for 2021 and plenty of courage for the 
soon coming new Ada standard ;-)

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

From: Randy Brukardt
Sent: Tuesday, January 5, 2021  9:45 PM

Thanks. Double periods often occur when a period is added to the end of new 
(inserted) text, but the original (deleted) text does not delete the ending 
period. Most of these have be in the AARM for a long time. (It's hard to look
for double periods as they commonly appear in ranges and slices.)

Note that as punctuation corrections, these fall under the category of 
"obvious typographical mistakes" and thus won't be marked in any way (just
corrected).

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

[From the AARM Review of Justin Squirek (October 2020) - Editor.]

---------
-- 4.7 --
---------

10.b/4: The corrigendum phrasing could be improved to be less repetitive:

"...cases when this could be the case are likely to be rare (the qualified 
expression would have to have a stricter subtype than the following usage) 
and the check is more likely to detect bugs than be unexpected."

to

"...cases [where this scenario arises] are likely to be rare (the qualified 
expression would have to have a stricter subtype than the following usage) 
and the check is more likely to detect bugs than be unexpected."

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

[From the AARM Review of Richard Wai (October 2020) - Editor.]

4.4(9.a/5)
 
"a" should be "an":

"... "True" is a{n} operative constituent of the expression ..."

4.5.2(39.v/5)
 
There appears to be a word missing

"..., which would be confusing and would {cause} various 
semantic difficulties"

4.5.5(18.a)

"types" should not be plural here

"... operands of any fixed point type[s] (not necessarily the 
same)..."

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

[From the AARM Review of Steve Baird (October 2020) - Editor.]

6.1.1

   We replaced almost all, but not all,
      "prefix of an Old attribute"
   occurrences with
      "prefix of an Old attribute_reference"
   Should we fix the two that were missed (27.g/5,
   43.j/5)?

[Editor's note: There's similar wording in 27.h/5, 27.j/5, and 43.i/5. Also,
in such uses "prefix" needs to be in the syntax font (as in the normative 
wording).]

6.4.1 -

   In 6.b.1/4, at least a missing word:
      We assume the worst in a generic body [regarding] whether or not a
      formal subtype has a constrained partial view

   Perhaps also drop the "or not"?
      We assume the worst in a generic body regarding whether a
      formal subtype has a constrained partial view.

In 6.5(22.b/5) we've got
      The permissions of 11.4.2 ensure that duplicate evaluation of a
      predicate at a single point is never required,

   I looked at the implementation permissions section of 11.4.2 and
   didn't see anything like that.

[Editor's reply: I think that the later two rules of 11.4.2 have that effect
in all but pathological cases (such as a random generator or clock used in a
predicate, such cases are not portable by the last permission of 11.4.2). But
"never" is too strong. I'll weaken it.]

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

[Inspired by the AARM Review of Bob Duff (October 2020) - Editor.]

The incompatibility description for added entities in language-defined
packages is long-winded and redundant. We can reduce the amount of text
by describing a "use-clause conflict" once and using that in each of the
individual incompatibility descriptions.

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

[A summary of the conclusion of a private discussion - Editor.]

We used static rules on SAOAATs (stand-alone objects of an anonymous access
type) to prevent putting a more nested object into one (which does cause
issues). In particular, we have in 3.10.2(13.3/4):
 
   The accessibility level of the type of a stand-alone object of an anonymous 
   access-to-object type is the same as the accessibility level of the type of
   the access value most recently assigned to the object[; accessibility
   checks ensure that this is never deeper than that of the declaration of 
   the stand-alone object].

...but there is no justification given for the "redundant" part (in square 
brackets). There should be an AARM note explaining this. The "normal case"
says that there is no static check by by 3.10.2(19/5) & 3.10.2(19.2/5) (or
the rule that was there before this version).

(After much discussion) The entire rule of 4.6(24.17/4) says:
 
   The accessibility level of the operand type shall not be statically deeper 
   than that of the target type, unless the target type is an anonymous access
   type of a stand-alone object. If the target type is that of such a
   stand-alone object, the accessibility level of the operand type shall not 
   be statically deeper than that of the declaration of the stand-alone object.

Essentially, conversion to a SAOAAT's type uses a separate static check, and
that is what is referred to in 3.10.2(13.3/4).

As such, there should be a "The Proof" after 3.10.2(13.3/4) pointing at 4.6, 
something like "Conversions into the anonymous access type of a stand-alone
object use a stricter (static) accessibility rule - see 4.6; these checks
are those referred to above."

Another issue: Is it clear that when the "statically deeper relationship does 
not apply" that any Legality Rules about that relationship are not enforced?? 
The wording in 3.10.2 rather tip-toes around that by saying that it neither 
deeper nor shallower, but how that applies to Legality Rules (or other rules)
is not specified. One could easily imagine that all of the rules fail in that
case. There is an AARM note 3.10.2(19.a/3) that mentions dynamic checks, it
probably should mention static checks as well. Perhaps:

    In these cases, {no static accessibility checks are made, and} we use 
    dynamic accessibility checks{ to prevent problems}.

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

From: Christoph Grein
Sent: Wednesday, April 28, 2021  3:14 AM

In subclauses C.6.1 and C.6.2, the referenced AI is wrong (AI05-0234-1).

This should be AI12-0234-1.

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

[From WG 9 review, issue 12.]

10.2(18.c) mentions RM95; this is a generic reference and should just say "RM".

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

[From WG 9 review, issue 21.]

11.4.1 (15.b/2) "Ramification: This routines are used to define the stream
attributes (see 13.13.2) for Exception_Occurrence."

"This routines" should be "These routines".

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

[From WG 9 review, issue 108.]

13.3 (38.l) Typo: "The nonnegative part is missing from RM83 (for mod_clauses, 
[n]{s}ee alignment_clauses, which are an obsolete version of Alignment 
clauses)."

[Editor's reply:

I think "nee" here was used in the sense of "AKA", not a misspelling of "see".
It would be better to avoid any of these and spell this out (of course, no
one has complained for 25+ years and many reviews, but still). Thus I used:

...  (for mod_clauses, [nee]{known in Ada 83 as} alignment_clauses, which ...]

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

From a private discussion about Put_Image:

>>>>The RM says: 
>>>>   The image written out for a record having no components (including any 
>>>>   interface type) is "(NULL RECORD)".
>>>>
>>>>So the default implementation for an interface type is not a null procedure 
>>>>(which would write out nothing at all).

>>>That is pretty awkward, since the user isn't allowed to "confirm" such an 
>>>aspect, unless the make the denoted subprogram something other than a 
>>>primitive.  Not impossible, but a bit painful. Not impossible, but a bit 
>>>painful.  I also notice that whatever an interface does is pretty much 
>>>irrelevant, except in the weird case when you explicitly convert to the 
>>>interface type, because of the following rule in 4.10(15/5):
>>>
>>>For a type extension, the default implementation of T'Put_Image depends on 
>>>whether there exists a noninterface ancestor of T (other than T itself) for
>>>which the Put_Image aspect has been directly specified. If so, then 
>>>T'Put_Image will generate an image based on extension aggregate syntax where
>>>the ancestor type of the extension aggregate is the nearest ancestor type 
>>>whose Put_Image aspect has been specified. If no such ancestor exists, then
>>>the default implementation of T'Put_Image is the same as described below for
>>>a nonderived record type.
>>>
>>>Interestingly, this rule doesn't properly handle the "confirming aspect 
>>>specification has no effect" since there is no way to "confirm" an 
>>>implicitly composed Put_Image for a tagged type without interfering with 
>>>the way the above rule works.  We probably ought to have an AARM note 
>>>indicating we "know" that this violates our general rule.  Basically, the
>>> whole notion of "confirming" an implicitly composed aspect doesn't really 
>>>make sense. 
>>
>>I don't think it makes sense to worry about "confirming" an implicitly 
>>constructed subprogram; it is by definition impossible to confirm such a 
>>thing, since anything you could specify is *not* by definition the implicit
>>constructed subprogram (it's some explicit subprogram, the effect might be 
>>the same, but that not how "confirming" is defined and it would be a
>>slippery slope to define in any useful way). There are plenty of aspects 
>>like that; for instance, you can't specify the default for Default_Value 
>>(which is that there isn't a default value - any specification is 
>>necessarily not that).
>>
>>It might make sense to add an AARM note after the definition of "confirming" 
>>that that is expected that it might not be possible to specify a confirming 
>>aspect, and give the Default_Value and stream attribute examples. Beyond 
>>that, I don't think it is worth obsessing over.
>
>I agree with your sense that "confirming" doesn't really make sense for some 
>aspects (though we went out of our way to provide something to represent 
>"Unspecified" for Global), including for all "implicitly composed" aspects.

I've already handled the AARM note, adding after 13.1(18.2/5):

Discussion: As noted at the beginning of this subclause, we have a language
design principle that confirming aspects do not change the semantics. However,
it is not a language design principle that one can always specify a confirming
aspect. Some aspects can never be confirmed. For instance, the default 
implementation of a stream-oriented attribute cannot be confirmed, as any
subprogram that can be specified is not the same as the default subprogram,
and thus is nonconfirming. Whether the effect is the same is not relevant
for this purpose; it would be very difficult to formally define what it means
to have the same effect. (Note that one can name any implementation for a 
stream-oriented attribute by using the associated attribute but specifying 
that by name would violate the circular aspect definition rule.) This is true
for any implicitly composed aspect. Similarly, aspect Default_Value cannot be 
confirmed as the default is that there is no default value; any value that can 
be specified is not that. Other aspects are similar.

So a comment on that isn't needed. A comment on the other topics is still
needed, of course.

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

[From WG 9 review, issue 12.]

13.11.5 (3.a)/5 says: We can't use the do notation {(see ??.??)} as that 
requires a statically denoted dispatching argument (we have a function call
here).

Not sure what is meant by "do notation". Could we please add a "(see x.x)" 
reference after "do" to point the reader to some place where this is defined?

Editor's reply:

The "do notation" was a forerunner of the Dispatching aspect; apparently, no 
one noticed this note when that other construct was changed. So I will change
"do notation" to "Dispatching aspect (see H.7.1)". This will be recorded in 
AI12-0005-1.

A minor additional quibble: the Dispatching aspect requires a statically NAMED 
object, not a statically DENOTED object. (That also was a late change.) And 
"object" is better here than "dispatching argument".

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

[From WG 9 review, issue 102.]

13.1(14.k/5) says "We need this rule even though static matching explicitly 
excludes confirming values of Object_Size. That's because a general access 
type can designate any aliased object whose subtype statically matches the 
[the] designated subtype. "

Delete one of the two consecutive "the"s. Doesn't matter which one. ;)

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

[From WG 9 review, issue 101.]

13.1(14.i/5) says "The same issues apply to Alignment. Similar issues apply 
to Object_Size, Static_Predicate, and Dynamic_Predicate, but the chosen 
solution is different: explicit rules in 4.9.1 [to] ensure that the aspects
are the same if specified."

Delete "to".

Editor's comment:

It feels to me that we need some word there (or we would need to drop 
"ensure"). The "chosen solution" is "explicit rules in 4.9.1" and we then 
explain what the rules do. Perhaps "that" would be better than "to": "... 
explicit rules in 4.9.1 [to]{that} ensure that ...".

I put this into AI12-0005-1 (as AI12-0059-1 is already WG 9 Approved and thus
cannot be changed).

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

[From WG 9 review, issue 146.]

AARM 7.6(17.q/3): This "To be honest" refers to the "parent part" of an 
extension aggregate. The correct term is "ancestor part" (RM 4.3.2 (2)).

Same comment applies to 7.6.1 (24.k/2).

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

[From WG 9 review, issue 147.]

AARM 7.6.1(18.c) says that "The goto statement will first cause Finalize(Y) 
to be called." However, RM 7.6.1 (11/3) says that objects are finalized in 
the reverse order of their creation, so Finalize(Z) should be called before
Finalize(Y), because Z is declared (and created) after Y. The easiest fix 
is to reverse the order of the declarations of Y and Z in the example.
Note that RM 7.6.1 (19.a) also refers to this example and to Z.

[Tucker Taft replied:
Another good catch! Reversing the declaration order of Y and Z is likely to 
lead to other confusion. I would suggest we systematically swap Y and Z 
references to be consistent with the finalization-is-in-reverse-order 
requirement.]

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

[From WG 9 review, issue 136.]

Typo in 4.4(9.a/5): "opertive".

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

[From WG 9 review, issue 117.]

John Barnes wrote:

A.18(12.l/5) Containers "...behavior of the sorts when ... " might be better
as "... behavior of sorting when..." Sorts to me relates to feeling out of 
sorts (too much gin) or confectionary (liquorice allsorts).

Editor's reply:

Being rather pendantic, we don't define anything called "sorting" (we do use 
the term informally a few times); what we do is define routines named Sort or
<something>_Sort. They usually "reorder" elements so they are left "sorted". 
So "the sorts" is short for the "various Sort or <something>_Sort procedures".
That's too long for this note, but maybe "the Sort procedures" is close 
enough?

Put this into the AARM AI.

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

[From WG 9 review, issue 98.]

13.1(8.oo): 
    aspect Exclusi[on]{ve}_Functions

Misnamed aspect

Editor's reply:

Additionally, many of these paragraphs (including this one) are misnumbered, 
they should be inserted (8.mm.xx) and have /5.

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

[From WG 9 review, issue 172.]

A typo (an extra 'a' in "streaam") occurs in both 13.13.1 and A.12.1 (in 
the AARM)

In 13.13.1(37.a/5) and A.12.1(36.h/5).

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

[From WG 9 review, issue 39.]

12.5(10.a) imprecise wording, "floating point" is not an ancestor of a type

  Ramification: The term “formal floating point type” refers to a type defined 
  by a formal_floating_point_definition. It does not include a formal derived 
  type whose ancestor is {a} floating point {type}. 

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

[From WG 9 review, issue 170.]

Is this Ramification true if the component subtype of the string has 
predicates? Example: the subtype contains all and only the vowel letters.

[Editor's response:]
Good catch. I prefixed this with "If no predicates apply to the component
subtype, ...".

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

[From WG 9 review, issue 167.]

4.9 (13.b) In this "Ramification", the last case, "when specifying the 
value of a discriminant ...", is no longer exactly true, because a nonstatic
value is now allowed if the value has a static subtype that governs the 
variant part, RM 4.3.1(17/5).

[Editor's response:]

You are correct. Moreover, this note reads as if this is a complete list of
places where static expressions are required. But there has been no 
maintenance of this list in Ada 2005, Ada 2012, or Ada 202x, and it is almost
certainly missing some constructs. It would be better to reduce it to a few 
interesting cases as examples, because no one is ever going to remember to 
maintain a list like this, (Rather, the complete list should be in the index
as "static expression, required", but that's another can of worms at this 
late date - trying to find all of the places would be a pain.)

Anyway, I replaced the entire note with:

The language requires a static expression in a number_declaration, a numeric 
type definition, certain representation items, and a number of other contexts.

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

[From WG 9 review, issue 163.]

C.6 (19.c/5) This "Implementation Note" follows a rule for full access objects,
but does not say anything about full access objects. It seems the sentence that
starts "If the record object is atomic then..." should instead start "If the 
record object is a full access object then...".

[Editor's response:]

Since there is a such a thing as a volatile full access object, that's 
insufficient as we do want to talk about the case of atomic reads and writes.
So I think we need "... is an atomic full access object then ...".

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

[From WG 9 review, issue 46.]

E.2.2 (17.c/4): minor grammar fix:

    Discussion: This could be accomplished via a self-referencing pointer or 
    via squirrelling {away} a writable pointer to a controlled object. 

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

[From WG 9 review, issue 48.]

G.1.1(25.c/5) says:

    Ramification: {AI12-0241-1} A nongeneric pure unit is always nonblocking, 
    so we don't need to talk about the Nonblocking aspect of these packages. 
    Similarly, a nongeneric pure unit always has the Global aspect set to 
    null, so we don't need to talk about that, either. 

The above is true, though there is no distinction between nongeneric and 
generic pure units at this point with respect to these rules (per 9.5(33/5)).
So we should drop "nongeneric" here.

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

[From WG 9 review, issue 96.]

3.10 (26.m/3), 6.3.1 (26.l/5), 6.5 (28.q/3), 9.4 (35.g/3) use
"Keyword" instead of "Reserved Words".

[Editor's reply:]
"Reserved words" are informally known as "keywords" in the AARM; "keyword" 
is easier to understand in many contexts as one short word rather than a 
clunky phrase. And changing all of these places (several quite old) is 
unappealing. I added an AARM definition to 2.9 to make this clear.

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

[From WG 9 review, issue 109.]

13.3(55.l) reads
"The programmer might think that My_Device'Size is 8, and that 
My_Device'Address points at an 8-bit location. However, this 
[is not]{might not be] true."

It might be also be true, depending on the hardware, implementation, etc

[Steve Baird suggested using "not guaranteed to be" True. Tucker Taft agreed.]

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

[From WG 9 review, issue 135.]

In AARM 4.3(3.c/5), I was briefly confused reading
Thus, we allow ... ..., even though only delta_aggregates
allow private types or extensions.

What wasn't clear at first was that the word "private" applied not just
to "types" but also to "extensions". Would it be clearer to
say "private types or private extensions"?

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

[From WG 9 review, issue 131.]

In 6.1.1, we use the term "inherited" or "inheritance" inappropriately to 
refer to class-wide pre/postconditions (which apply to corresponding 
subprograms in descendant types, but are not "inherited" in the usual sense)
in AARM paragraphs 3.c/3, 5.a/3, 16.d/3, 16.e/3, 18.a/4, 18.b/4, 19.a/3,
37.a/3, 37.b/3, 38.a.1/5, 44.f/4. The only ones that are probably worth 
fixing are 3.c/3 and 5.a/3, because they are used as the "official" aspect
descriptions. For the others, I would suggest we add a warning that we use
the term "inherited" informally with respect to class-wide
pre/post-conditions, to mean that the aspect applies to corresponding 
subprograms in descendant types. For 3.c/3 and 5.a/3, we might want to use 
the correct terminology, namely:

    3.c/3 Aspect Description for Pre'Class: Precondition [inherited on type 
    derivation]{that applies to corresponding subprograms of descendant types}.

    5.a/3 Aspect Description for Post'Class: Postcondition [inherited on 
    type derivation]{that applies to corresponding subprograms of descendant 
    types}.

Then, I would suggest:

Add after 6.1.1(5.a/3):

    In the AARM notes below, we use the terms "inherited" and "inheritance" 
    informally with respect to class-wide pre/post-conditions, to mean that 
    the aspect applies to corresponding subprograms in descendant types.

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

[From WG 9 review, issue 140.]

In 4.6(21.l.1/4) we've got
"We assume the worst in a generic body whether or not a formal subtype
has a constrained partial view; specifically, ... "

Should a word like "regarding" or "about" be inserted, as in
"We assume the worst about whether ..." (Yes.)

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

[Editor's note (Sept 12, 2021):] The (see 5.2.1) is in the wrong place
in 2.2(14.e/5), Draft 32. It appears to apply to "list of delimiters"
rather than "target name symbol".

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

[Editor's note (Sept 12, 2021):] A.16(131.g/5) has "deescribed".

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

[Editor's note (Sept 12, 2021):] A.18(12.f/5) is misplaced, it has 
nothing to do with this subclause.

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

From: Steve Baird [privately]
Sent: Thursday, July 22, 2021  4:11 PM

missing period before "See" in M.2 (73.3)
   The result for Directories.Size for a directory or special file See
   A.16(93/2).

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

From: Steve Baird [privately]
Sent: Friday, July 23, 2021  1:25 PM

"The circumstances the implementation passes in the null value for a view
  conversion of an access type used as an out parameter."

Strictly speaking, probably should be "The circumstances in which ...".
In similar cases elsewhere in this section, we use "The circumstances 
where ...".

Either would be an improvement.

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

From: Steve Baird [privately]
Sent: Monday, July 26, 2021  4:56 PM

Two cases of Ada.Calendar.Formatting being misspelled with only one "t".

9.6.1(86.a/2)
M.2 (26.1/2)

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

Editor's note (November 12, 2021): All of the items above this
marker have been included in the working version of the AARM.

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


Questions? Ask the ACAA Technical Agent