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

--- ai12s/ai12-0005-1.txt	2020/10/16 04:42:34	1.40
+++ ai12s/ai12-0005-1.txt	2020/12/04 07:59:28	1.41
@@ -2472,7 +2472,300 @@
 
 ***************************************************************
 
-Editor's note (October 15, 2020): All of the items above this
+[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.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.]
+
+***************************************************************
+
+Editor's note (November 23, 2020): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************