!standard 12.03 (11) 06-03-15 AI05-0005-1/00 !class confirmation 06-03-15 !status received 06-03-15 !priority Low !difficulty Easy !qualifier Omission !subject Editorial comments on AARM 2005 !summary This AI serves as a holder for editorial comments on AARM-only annotations. This AI serves the same purpose as AI95-00114 for Ada 2005. 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: Stephen Leake Sent: Tuesday, April 18, 2006 7:04 PM I'm reading the Ada 2005 LRM "cover-to-cover" (to be sure I know about all the new stuff), and noticed that paragraphs 3.1 7, 8 are identical. I suspect 8 should be deleted. **************************************************************** From: Tucker Taft Sent: Wednesday, April 19, 2006 12:57 PM Good point! **************************************************************** From: Randy Brukardt Sent: Wednesday, April 19, 2006 1:09 PM Note that all of the paragraph numbers of that clause (after number 7) are wrong (because of the extra junk paragraph). This bug is only in (draft 16 of the) RM/AARM, and not in the Amendment proper. **************************************************************** From: Randy Brukardt Sent: Wednesday, December 20, 2006 8:35 PM 10.1.4(5.e/2) says that the "second" rule applies, but there is only one (very long) sentence in 10.1.4(5). 10.1.4(5.e/2) should say that the "consistency" rule applies so that there is no ambiguity. **************************************************************** From: Pascal Leroy Sent: Wednesday, January 3, 2007 1:39 PM I am looking at the example in 3.10.1(2.a-2.d), and specifically at the first comment in 3.10.1(2.d). I surely hope that this comment is incorrect, otherwise adding "with P" in front of the body of P would change the semantics. Surely we did not design a language where withing yourself has any observable effect... I actually think that this comment is just inconsistent with the rules: even if you are in the scope of a nonlimited_with_clause for P, 3.10.1(2.4/2) doesn't apply because the completion of T is not declared in a visible part. I am not exactly sure how the example should be modified. Perhaps it should say "note that the second rule ensures that a nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the completion of T". **************************************************************** From: Randy Brukardt Sent: Wednesday, January 3, 2007 12:20 PM > I actually think that this comment is just inconsistent with the rules: > even if you are in the scope of a nonlimited_with_clause for P, > 3.10.1(2.4/2) doesn't apply because the completion of T is not declared in > a visible part. Yes, that's obviously true. > I am not exactly sure how the example should be modified. Perhaps it > should say "note that the second rule ensures that a > nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the > completion of T". I think the entire part after the comma should be dropped. I don't think anything useful can be said for this example. The sentence is nonsense in any case, because we know that "with P.C" is the same as "with P, P.C;". This is just the example of why we need the "in whose visible part", and it hardly makes sense to mention the other case (it would be a very different example). **************************************************************** From: Pascal Leroy Sent: Thursday, January 4, 2007 9:44 AM Another one to put in this AI: 4.1(7/2) has apparently been changed by the Amendment (otherwise it wouldn't say /2, right?) but it has no cross-reference to an AI. **************************************************************** From: Randy Brukardt Sent: Thursday, January 4, 2007 12:27 PM This is one of the changes from AI05-0004; the tools didn't support such cross-references when those were put in. That needs to be done, and the version really ought to be /3 on those (see AI95-0004 for a complete list). **************************************************************** From: Randy Brukardt Sent: Friday, January 12, 2007 6:53 PM The reason behind the first half of 10.2.1(15.3/2) is very obscure, the AARM Reason note should explain: Such an allocator would provide a backdoor way to get a global variable into a pure unit, so it is prohibited. Most such allocators are illegal anyway, as their type is required to have Storage_Size = 0. But access parameters and access discriminants don't necessarily disallow allocators. However, a call is also illegal here (by the preelaboration rules), so access parameters cannot cause trouble. So this rule is really about prohibiting allocators in discriminant constraints: type Rec (Acc : access Integer) is record C : Character; end record; Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal. The second half of the rule is needed because aggregates can specify the default initialization of a private type or extension using <> or the ancestor subtype of an extension aggregate. The subtype of a component could use an allocator to initialize an access discriminant; the type still could have a pragma Preelaborable_Initialization given. Ada 95 did not allow such private types to have preelaborable initialization, so such a default initialization could not have occurred. Thus this rule is not incompatible with Ada 95. **************************************************************** From: Randy Brukardt Sent: Tuesday, January 16, 2007 5:53 PM The rules 4.3(3/2), 4.3.1(8/2), 4.3.2(4/2), and 4.3.3(7/2) can be confusing. These are the rules that determine how an aggregate is resolved. Tucker says (privately) that these rules are "additive"; 4.3(3/2) says don't look inside an aggregate until you have a single array, record, or record extension type. 4.3.1(8/2) says that you don't start considering the "record aggregate" possibility until you have a single record or record extension type. And so on. There should be AARM notes that explain this on 4.3(3/2) and 4.3.2(4/2). (There are already notes on 4.3.1(8/2) and 4.3.3(7/2). After 4.3(3/2), we should have something like: AARM Ramification: There are additional rules for each kind of aggregate. These aggregate rules are additive; a legal expression needs to satisfy all of the applicable rules. That means the rule given here must be satisfied even when it is syntactally possible to tell which specific kind of aggregate is being used. After 4.3.2(4/2), we should have something like: AARM Ramification: This rule is additive with the rule given in 4.3. That means that rule must be satisfied even though it is alway syntactally possible to tell that something is an extension aggregate. Specifically, that means that an extension aggregate is ambiguous if the context is overloaded on array and/or record types, even though those are never legal contexts for an extension aggregate. Thus, this rule acts more like a legality rule than a name resolution rule. **************************************************************** From: Randy Brukardt Sent: Monday, January 22, 2007 8:53 PM The mail on AI05-0037 says (on the topic of whether <> needs to be added to any existing aggregate wording): 4.3.3(23) worried me a bit, but I concluded it is already OK. <> means the component "initialized by default". If there are multiple associated components, each one will be initialized by default (and if that means that each component ends up with a different value, so be it). It doesn't say that one component is initialized by default, and then others are copied from it. 4.3.1(20) also appears worrisome. But here it doesn't make sense to talk about "for each associated component" in the case of <>, because we're considering the value of <> for each individual associated component. (see 4.3.1(19.1/2)). And each component has its own default expression or its own default initialization. After all, even the types of the components can be different for a single association. It might make sense to add an AARM note to make that point clear (for both 4.3.1(20) and 4.3.3(23)), but I don't think any wording changes are needed. **************************************************************** From: Randy Brukardt Sent: Friday, February 16, 2007 10:53 PM AC-0140 says that improved AARM notes are needed in 3.10.2(3), 3.10.2(29), and 13.10(3). Here are those notes: 3.10.2(3): Discussion: The Unchecked_Access attribute acts as if the object was declared at library-level; this applies even when it is used as the value of anonymous access type. See 13.10. 3.10.2(12.1): Ramification: If the value for this rule and the next one is derived from an Unchecked_Access attribute, the accessibility is library-level no matter what the accessibility level of the object is (see 13.10). 3.10.2(13): Ramification: If the value of the actual is derived from an Unchecked_Access attribute, the accessibility is always library-level (see 13.10). 13.10(3): Ramification: We say "rules and semantics" here so that library-level accessibility applies to the value created by X'Unchecked_Access as well as to the checks needed for the attribute itself. This means that any anonymous access values that inherit the accessibility of this attribute (such as access parameters) also act as if they have library-level accessibility. We don't want the "real" accessibility of the created value re-emerging at a later point - that would create hard-to-understand bugs. **************************************************************** From: Randy Brukardt Sent: Friday, March 23, 2007 7:55 PM 3.9.1(4.c/2) should talk about subprograms that require overriding, not abstract subprograms. (While the example only talks about abstract types, the problem can happen with all types being concrete; consider deriving directly from type TT in the generic body.) **************************************************************** From: Randy Brukardt Sent: Wednesday, March 28, 2007 8:52 PM 10.1.2(11.j/2) is no longer needed as a To be honest rule, as the normative wording now says this (see AI95-00220). It isn't very worthwhile as a note, so it should be deleted. **************************************************************** From: Randy Brukardt Sent: Tuesday, April 10, 2007 9:12 PM AC-141 talks about a confusion in reading the wording of 8.3.1(5/2). It's thought that alternative readings don't make much sense, but adding an AARM note would be helpful: To Be Honest: This doesn't require that the overriding happen at precisely the place of the declaration or body; it only requires that the region in which the overriding is known to have happened includes this place. That is, the overriding can happen at or before the place of the declaration or body. **************************************************************** Editor's note (April 10, 2007): All of the items above this marker have been included in the working version of the AARM. **************************************************************** From: Robert A. Duff Sent: Friday, January 19, 2007 3:43 PM I just got my "author's copies" of the Ada RM published by Springer. Thank you, Randy. And my name, and several others, appear prominently on the cover. Cool. However, I have a concern: The name "Jean Ichbiah" appears nowhere, as far as I can tell, in the RM nor AARM. This seems like an outrageous lack of proper attribution. Is there some way to correct it, at this late date? What about the members of JDI's team? The "Acknowledgments" sections of this document commemerate many people -- but the pre-95 folks are left out. **************************************************************** From: Tucker Taft Sent: Friday, January 19, 2007 4:55 PM I don't remember what process was used to produce the "front material" of the Ada 95 standard. But if you look at it in comparison to the Ada 83 "green book," the Ada 83 "foreword" which was effectively the acknowledgments was not officially part of the standard (or at least that is what it says at the bottom of the page). In the Ada 95 standard, the "foreword" is some boilerplate provided by ISO, and makes no acknowledgments to authors. There is an "acknowledgments" page in the Ada 95 standard, but since there was no direct equivalent in the Ada 83 standard, I suspect it was developed from scratch, and I think we presumed it was obvious that this was an acknowledgment about the revision process, not about the original standard. It does seem a bit unfortunate that there is no acknowledgment to the original Ada language team, but I certainly don't feel anyone should blame Randy for the current situation. If anyone goofed, it was the Ada 9X team. **************************************************************** From: Pascal Leroy Sent: Saturday, January 20, 2007 3:41 AM > What about the members of JDI's team? The "Acknowledgments" > sections of this document commemerate many people -- but the > pre-95 folks are left out. I definitely agree. I actually find it quite outrageous that the original team is not mentioned (I am not blaming anyone, I'm sure it was not on purpose, but it's certainly unfair). What do we do about this? We are certainly not going to reprint the paper copies. I would also object to modifying the PDF and HTML files, since it is essential that they remain as close as possible to the printed version. We took extra steps (e.g., publishing SHA-1 signatures) to ensure that people would not be confused about which version is the "right" one. We don't want to start changing those files at the drop of a hat. My view is that if you make a mistake, the best you can do is to own up to it. My suggestion would be add on the official page for the Ada 05 RM (www.adaic.org/standards/ada05.html) a blurb like: "The development of Ada 95 and Ada 2005 would of course have been impossible without the strong foundation provided by Ada 83. As part of the numerous rounds of edits on the Reference Manual, the acknowledgments regarding the design team for the original language were unfortunately lost. We apologize for this error. The acknowledgment section for the Ada 83 language can be found ." Where the last word would hyperlink to a page containing the text of the acknowledgment section of RM 83. [Editor's note: A short acknowledgement based on the Ada 83 Foreword should be added in front of the Ada 95 acknowledgement. This is recorded here as this is text which does not appear in the actual Standard, so it shouldn't be mentioned in a real AI.] ****************************************************************