CVS difference for ai22s/ai22-0005-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai22s/ai22-0005-1.txt

--- ai22s/ai22-0005-1.txt	2023/10/07 08:03:05	1.8
+++ ai22s/ai22-0005-1.txt	2023/11/17 06:47:54	1.9
@@ -22,15 +22,10 @@
 
 !appendix
 
-From: John Barnes
-Sent: Tuesday, May 22, 2021 xx:xx PM
-
-... [Placeholder for the moment.]
-
-****************************************************************
-
 Editor's note (Nov 8, 2021): All of the items above this
-marker have been included in the working version of the AARM.
+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.)
 
 ****************************************************************
 
@@ -231,6 +226,131 @@
 > 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