Version 1.9 of ai22s/ai22-0005-1.txt

Unformatted version of ai22s/ai22-0005-1.txt version 1.9
Other versions for file ai22s/ai22-0005-1.txt

!standard 6.6 (6)          21-11-11 AI22-0005-1/00
!class confirmation 21-11-11
!status received 21-11-11
!priority Low
!difficulty Easy
!qualifier Omission
!subject Editorial comments on AARM 2022
!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, AI05-0005-1 did for Ada 2012, and AI12-0005-1 did for Ada 2022. 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.
!issue
!response
!appendix

Editor's note (Nov 8, 2021): All of the items above this
marker have been included in the working version of the AARM. (Some of 
the simpler items below have also been handled; these are marked [Handled]
temporarily.)

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

From: Niklas Holsti
WG 9 Review issue #167 - May 21, 2021

In this "Ramification" [4.9(13.b) - Editor.], 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).

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

From: Randy Brukardt
WG 9 Review issue #167 - May 25, 2021

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

If someone would like to develop a complete list of current places, I'd be 
happy to put index entries in for them all. In that case, I'd add to the above
" See 'static expression, required' in the index for a complete list of
places".

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

From: Tucker Taft
WG 9 Review issue #167 - May 27, 2021

I would defer the new index entry to the next revision. I would change
"places" to "contexts" in your new wording.

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

From: Randy Brukardt
WG 9 Review issue #167 - May 27, 2021

I've marked this "deferred" so we remember to add the missing index entries.

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

From: Randy Brukardt
In part from issue #19 - September 2, 2022

The profiles defined all should be indexed like "profiles, Ravenscar"
(similarly to restrictions).

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

From: Steve Baird
Sent: Wednesday, April 19, 2023 (privately)

Are we missing something in

    AARM Reason: For a function that has a parameter of T or access T, a blanket
    rule in 13.1.1 requires the function to be a primitive operation of T, the
    wording about the same declaration_list is redundant in that case.

? Perhaps something like

    AARM Reason: For a function that has a parameter of T or access T (so a blanket
    rule in 13.1.1 requires the function to be a primitive operation of T) the
    wording about the same declaration_list is redundant.

would be better.

This wording occurs twice in the AI.

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

From: Randy Brukardt
Sent: Friday, April 21, 2023 (privately)

How about:

   AARM Reason: For a function that has a parameter of T or access T, a blanket
   rule in 13.1.1 requires the function to be a primitive operation of T, so the
   wording about the same declaration_list is redundant in that case.

   [Editor's note: Fix both of the AARM notes in AI22-0002-1 (After
   AARM 4.1.6(3.b/3) and AARM 5.5.1(8.a/3)).]

I suspect this is what was meant to be written. The point is that the blanket
rule makes the wording redundant in this particular case. We have the case
first, the mention of the blanket rule, and finally the consequence.

One could imagine fully rewriting these notes to reorder the parts, but I haven't
found anything that works better.

Since AI22-0002-1 is WG 9 approved, I'll put this wording fix into AI22-0005-1
(the AARM note AI). No ARG action is needed.

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

From: Github issue #66, Tucker Taft
Sent: September 7, 2023

Section A.8.2, File Management, has useful descriptions of several operations
applicable to almost all kinds of files. But these appear nowhere in the Index
of the RM. That seems like an oversight.

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

From: Github issue #66, Randy Brukardt
Sent: September 28, 2023

This isn't really a "bug report", since the index is non-normative. Rather, it
is handled through the informal AARM update process. I've added this topic to
AI22-0005-1 where all of the AARM fixes live, and closed this topic.

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

From: Github issue #70, Steve Baird
Sent: September 28, 2023

We've currently got: [In AI22-0067-1 - Editor.]

   Add after 4.3.3(31):

      The nominal subtype of an array_aggregate (other than a subaggregate)
      is constrained by the values defined for its bounds and those of any
      subaggregates.

For AARM, add after that:

   To be honest:
      If an array_aggregate has more than one subaggregate corresponding to
      the same index, then the bounds of the first such subaggregate determine
      the constraint of the nominal subtype of the array_aggregate
      for that index.

Given the current language definition (and, in particular, the RM's uses of
"nominal subtype"), there does not appear to be any need to mention the
case where some but not all of the subaggregates corresponding to a given
index have static bounds. One could imagine something like "use static
bounds if they are available; otherwise take the bounds from the first
subaggregate" but this does not appear to be necessary.

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

From: Github issue #70, Randy Brukardt
Sent: September 29, 2023

The proposed note seems like unjustified overspecification to me. We know that
the bounds of all such subaggregates have to be the same, if not, Constraint_Error
will be raised. If that happens, nothing that depends upon the nominal subtype
can be executed. So, it doesn't matter which set of bounds is selected, and we
should let the implementation pick whatever is convenient for it. Ergo, I think
a better note would be something like:

   Ramification: If an array_aggregate has more than one subaggregate
   corresponding to the same index, then Constraint_Error will be raised unless
   all of the bounds of such subaggregates are the same. If Constraint_Error
   is raised, no code that could depend upon the details of the nominal subtype
   of the aggregate could be executed. Therefore, the implementation can use
   whichever such subaggregate is convenient to determine the bounds of the
   nominal subtype.

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

From: Github issue #70, Steve Baird
Sent: October 2, 2023

I (now) like Randy's idea that the implementation simply gets to pick one of
the candidates, but we don't specify which one since the choice doesn't really
matter. I'd still rather see some mention of this in an AARM note, as opposed
to saying nothing, since otherwise it looks like a hole (even if it isn't). I
don't feel strongly about it.

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

From: Github issue #70, Tucker Taft
Sent: October 2, 2023

> I (now) like Randy's idea that the implementation simply gets to pick one
> of the candidates, but we don't specify which one since the choice doesn't
> really matter.

Agreed.

> I'd still rather see some mention of this in an AARM note, as opposed to
> saying nothing, since otherwise it looks like a hole (even if it isn't).

I agree that there is a danger that all those Steve Baird clones out there
will be hammering on us with ARG GitHub issues if we don't add the note. ;-)

> I don't feel strongly about it.

But strongly enough, it seems, so we should add the note!

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

From: Randy Brukardt
Direct to this AI; Wednesday, October 11, 2023

AI22-0006-1 has AARM notes AARM 4.1.6(3.b/3) and AARM 5.5.1(8.a/3),
which contain the supposed syntax term "declaration_list". But there is no
such syntax; there is a defined term "declaration list" and that is what is
meant by these notes. That has been corrected in the RM draft.

[Handled]

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

From: John Barnes (privately)
Sent: Monday, October 23, 2023  9:11 AM

I am toiling with updating my wretched book. I noticed that K 34.1/5 says

Iterator_View An alternative type to used for container element iterators. See 5.5.1.

It needs a be before used.

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

From: Randy Brukardt

Annex K is a generated annex; the original source is found in the AARM, in this
case 5.5.1(9.d/5). We need to correct that note to correct the annex; thus the
change is recorded in the AARM AI (AI22-0005-1).

[Handled]

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

From: Christoph Grein
Sent: Thursday, November 16, 2023  8:25 AM

!topic ... allowed by the Global aspect of{ }A, then...
!reference Ada 2022 AARM13.13.2(37.a/5)
!from Christoph Grein 2023-11-16
!discussion A funny coincidence with my previous mail - the very same paragraph
number in a different subclause.

[Handled]

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

From: Christoph Grein
Sent: Thursday, November 16, 2023  8:25 AM

!topic Unfortunate wording 
!reference Ada 2022 AARM13.13.1(37.a/5)
!from Christoph Grein 2023-11-16
!discussion

Reason: The Streams.Storage.Bounded package is provided in order to make
available an alternative to the Streams.Storage.Unbounded package *which
gives more predictable memory usage*.

I know what is meant (do I?) but I think the wording is unfortunate because
the part italicized above at first sight seems to reference the Unbounded
package.

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

From: Tucker Taft
Sent: Thursday, November 16, 2023  8:48 AM

Agreed.  Better might be:

Reason: The Streams.Storage.Bounded package is provided as an alternative
to the Streams.Storage.Unbounded package, but with more predictable memory
usage.

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

From: Vincent Marciante
Sent: Thursday, November 16, 2023  9:24 AM

How about:

The Streams.Storage.Bounded package is provided in order to make available 
an alternative means to store streams which  has more predicable memory usage
than the Streams.Storage.Unbounded package.

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

From: Randy Brukardt
Sent: Thursday, November 16, 2023  9:26 PM

I don't really like either of these, but something better seems doesn't seem easy to come up with.

Tucker suggested:

>Reason: The Streams.Storage.Bounded package is provided as an alternative
>to the Streams.Storage.Unbounded package, but with more predictable memory
>usage.

The "but" here is clunky, as there really isn't anything that we're opposing to.
Without it, the original problem returns.

Vincent suggested:

>The Streams.Storage.Bounded package is provided in order to make available
>an alternative means to store streams which has more predicable memory usage
>than the Streams.Storage.Unbounded package.

We've never talked about "storing streams", and that's not an accident. It's not the streams that are getting stored, but rather the data sent to them.

These packages are just an implementation of streams that don't use any files. Thus, they are just an in-memory implementation -- but we don't use that description, either, because "memory" isn't well-defined (in an RM sense).

Probably we need a more aggressive reordering:

The alternative package Streams.Storage.Bounded provides more predictable memory
usage than the Streams.Storage.Unbounded package.

Maybe even drop the alternative and explain the trade-offs better:

The package Streams.Storage.Bounded provides more predictable memory usage than
the Streams.Storage.Unbounded package, at the cost of needing to determine a
maximum number of stream elements that can be stored.

[Handled]

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



Questions? Ask the ACAA Technical Agent