!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] ****************************************************************