CVS difference for ai12s/ai12-0005-1.txt

--- ai12s/ai12-0005-1.txt	2021/05/28 05:01:08	1.48
+++ ai12s/ai12-0005-1.txt	2021/05/29 23:55:28	1.49
@@ -3421,7 +3421,87 @@
 
 ***************************************************************
 
-Editor's note (May 27, 2021): All of the items above this
+[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 (May 29, 2021): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************