!standard 6.6 (6) 11-11-11 AI05-0005-1/00 !class confirmation 11-11-11 !status received 11-11-11 !priority Low !difficulty Easy !qualifier Omission !subject Editorial comments on AARM 2012 !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 and AI05-0005-1 did for Ada 2012. 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. !question !response !appendix From: John Barnes Sent: Tuesday, May 22, 2012 3:11 PM ... Anyway, I just downloaded the latest version and hunting around for incomplete types and generics, I came across 12.5(16.i/3). It refers to AI-215 instead of AI-213. Rats. **************************************************************** From: Randy Brukardt Sent: Monday, January 14, 2013 9:26 PM AARM 3.9(12.d/2) uses "privateness", which is not a word. Use "privacy" instead. **************************************************************** From: Randy Brukardt Sent: Monday, January 14, 2013 9:26 PM AARM 9.6.1(4.a/2) has two minor errors. First there is a word missing: "... which are more than 12 hours {different }than UTC. ..." Second, "southern" is misspelled (the last 'n') is missing. **************************************************************** From: Randy Brukardt Sent: Friday, April 19, 2013 1:21 AM AARM 11.5(31.l/3) has a typo: ...inlining is never requir{ed}[ing],... **************************************************************** From: Tucker Taft Sent: Tuesday, February 26, 2013 5:10 PM I agree with both of you. [Editor's Note: The majority of this thread can be found in AC-00248.] The wording as given is inadequate, but the intent is as Randy stated: you may assume that if you evaluate an assertion expression once and it is True, you don't need to evaluate it again if all you are doing in the mean time is evaluating assertion expressions. *************************************************************** From: Steve Baird Sent: Tuesday, February 26, 2013 5:21 PM I'm happy to leave it at that. Let's either take no further action or, if anyone thinks it is worth the bother, add a brief AARM note based on Tuck's words above. *** Add an AARM note. *************************************************************** From: John Barnes Sent: Friday, June 7, 2013 9:13 AM The package Ada.Dispatching was Pure in Ada 2005 but has been downgraded to Preelaborable because of the addition of Yield. This is unlikely to be a problem. (AI-166, D.2.1) *** Incompatibility not mentioned in AARM When an inherited subprogram is implemented by a protected function, the first parameter has to be an in parameter, but not an access to variable type. Ada 2005 allowed access to variable parameters in this case; the parameter will need to be changed to access to constant by the addition of the constant keyword. (AI-291, 9.4) *** this is a BI, but it doesn't say correction in AARM *************************************************************** From: Randy Brukardt Sent: Monday, June 15, 2013 9:43 PM 3.10.2(7.b/2) talks about anonymous access types used in stand-alone type declarations and function results as having the level of the declaration. But neither of these are true anymore (they also have special rules). This note needs to be rewritten to talk only about components. *************************************************************** From: Randy Brukardt Sent: Thursday, October 24, 2013 9:43 PM The thread in AC-00254 makes it clear that the "resolution" rules 4.6(7) and 6.4.1(4) are not actually used for resolving overloading and the like. They exist specifically to prevent the "name" from being evaluated (which would happen by 4.4(10)) if they are part of an expression. That's why they used the weird wording of "interpreted as" rather than "shall be". This needs to be much clearer in the AARM Notes. AC-00254 has an example program that illustrates some of the oddities that would occur if these rules were used as resolution rules. Tested compilers do not do so, thus we add the notes to ensure that future compiler authors are not confused. *************************************************************** From: Steve Baird Sent: Friday, November 15, 2013 4:57 PM unhyphenated "class wide" in 6.5(5.d/3) "if the result type is class wide, then there must be an expression ..." *************************************************************** From: Randy Brukardt Sent: Wednesday, December 11, 2013 9:43 PM There is an unhyphenated "classwide" in 6.8(5.b/3). "...and the static classwide accessibility check cannot fail..." There are also occurrences in 3.7.2(3.b/3) [two occurrences], 7.6.1(9.b/3), 7.6.1(24.ee/3), and E.2.2(20.j/3). *************************************************************** From: Adam Beneschan Sent: Tuesday, February 4, 2014 10:03 AM Is there a reason why the Shift_*** and Rotate_*** subprograms defined in Interfaces (in B.2) aren't listed in Q.3, or was this an oversight? They also don't have their own Index entries. (By contrast, the subprograms in Interfaces.C, defined in B.3, are in both places.) *************************************************************** From: Randy Brukardt Sent: Wednesday, February 5, 2014 6:51 PM I can't find any documentation of the reason, but I think I omitted them because the contents of package Interfaces is formally implementation-defined. (See B.2(1) and especially AARM B.2(1.a)). As further evidence of this reasoning, note the difference between the handling of these packages for restriction "No_Implementation_Identifiers". In particular, all identifiers in Interfaces are considered implementation-defined (13.12.1(2.11/3) and 13.12.1(2.15/3)), while only added identifiers in Interfaces.C are considered implementation-defined (13.12.1(2.2/3) and 13.12.1(2.6/3)). As such, they're not "language-defined" identifiers and thus they don't belong in Annex Q. Note that you don't find Long_Integer or Short_Integer in Annex Q, either. (Given the special handling for Long_Integer and Long_Float for the purposes of restriction No_Implementation_Identifiers, perhaps they ought to be there.) They probably ought to be in the main index, but I probably forgot about them simply because the usual command does all of that automatically (it adds a subprogram to the Annex Q and main indexes with a single operation). Since I'm not using the usual command, I ended up not using any command. I'll fix that for future versions. P.S. Note that the indexes are non-normative, so these are treated like questions on the AARM; so this thread will be filed in AI12-0005-1 with other AARM questions. *************************************************************** From: Adam Beneschan Sent: Wednesday, February 5, 2014 7:21 PM > I can't find any documentation of the reason, but I think I omitted > them because the contents of package Interfaces is formally > implementation-defined. (See B.2(1) and especially AARM B.2(1.a)). B.2(1.a) looks a lot like 13.7(2.a/2), and the identifiers in System do appear in Annex Q. But I'll allow there are other differences there. 13.7(2) says "The following language-defined library package exists" about System, while B.2(2) doesn't use the word "language-defined". Also, the description of No_Implementation_Identifiers lists System in the same category as Interfaces.C. I guess it seems a bit odd to have an identifier that is "implementation-defined" as opposed to language-defined, but that the language requires implementations to define (since it's in the Implementation Requirements section). Also, the language does seem to define what the identifier is supposed to do. Perhaps these identifiers are is in some in-between state between language-defined and implementation-defined---a "Schrödinger's Identifier", maybe? Anyway, I was just wondering if the omission was a typo. If there's a reason behind it, that's OK with me (I don't normally look things up in Annex Q anyway). *************************************************************** From: Randy Brukardt Sent: Wednesday, February 5, 2014 8:04 PM ... > I guess it seems a bit odd to have an identifier that is > "implementation-defined" as opposed to language-defined, but that the > language requires implementations to define (since it's in the > Implementation Requirements section). Also, the language does seem to > define what the identifier is supposed to do. Perhaps these > identifiers are is in some in-between state between language-defined > and implementation-defined---a "Schrödinger's Identifier", maybe? I think that's right. The problem here is while there is a requirement that an implementation define a function Rotate_Left, the first argument to it has a type that is clearly implementation-defined. (Most implementations will have Unsigned_8, but other possibilities exist: our U2200 implementation had Unsigned_9 but no Unsigned_8, for instance.) So it's in a weird limbo halfway between language-defined and implementation-defined. Since 13.12.1 comes down on the side of implementation-defined, the Annex Q indexes do the same. > Anyway, I was just wondering if the omission was a typo. If there's a > reason behind it, that's OK with me (I don't normally look things up > in Annex Q anyway). The omission from the main index was clearly an oversight (although "rotate" and "shift" are indexed). The omission from Annex Q was on purpose, I think. *************************************************************** Editor's note (February 5, 2014): All of the items above this marker have been included in the working version of the AARM. ****************************************************************