!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). [Editor's note: This text meant that the location of the comment was within the scope of a nonlimited_with_clause for P.] **************************************************************** 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: 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.] **************************************************************** 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. **************************************************************** From: Adam Beneschan Sent: Friday, June 8, 2007 7:25 PM !topic Minor error in AARM 6.5 !reference AARM 6.5(5.f/2) !from Adam Beneschan 07-06-08 !discussion AARM 6.5(5.f) says about an extended_return_statement: "If the return statement is left without resulting in a return (for example, due to an exception propagated from the _expression_ or the _handled_sequence_of_statements_, or a goto out of the _handled_sequence_of_statements_), the return object is finalized prior to leaving the return statement. Is "expression" correct in this note? It would seem to me that if an exception is propagated from the evaluation of the expression, the return object is not initialized (according to the order that things are performed in 6.5(5.8)) and therefore does not need to be finalized (see 7.6.1(4)). **************************************************************** From: Gary Dismukes Sent: Friday, June 8, 2007 7:37 PM Looks like you're right about that. The return object can hardly be finalized if it hasn't even been created! (Fortunately that's only in the AARM.:) **************************************************************** !topic Bogus AARM information !reference AARM 7.6(21.b/2), AARM 7.6.1(24.c/2) !from Adam Beneschan 07-06-20 !discussion There are a couple places in the AARM that I believe provide incorrect information when dealing with a "built-in-place" function call. I saw these when I was trying to figure out what would happen with an extended return, and the information threw me off; it took some time before I figured out that the AARM was probably incorrect. Consider: with Ada.Finalization; package Pak1 is type String_Acc is access String; type Typ1 is new Ada.Finalization.Controlled with record F1 : Integer; F2 : Integer; F3 : String_Acc; end record; -- procedure Initialize (Obj : in out Typ1); procedure Adjust (Obj : in out Typ1); -- procedure Finalize (Obj : in out Typ1); function Func1 (Val : Integer) return Typ1; end Pak1; with Text_IO; package body Pak1 is procedure Adjust (Obj : in out Typ1) is begin if Obj.F3 /= null then Obj.F3 := new String' (Obj.F3.all); end if; end Adjust; function Func1 (Val : Integer) return Typ1 is begin return Ret : Typ1 do Ret.F1 := Val * 2; Ret.F2 := Val * 3; Ret.F3 := new String' (1 .. Val => '?'); end return; end Func1; end Pak1; with Pak1; procedure Test1 is Z : Pak1.Typ1 := Pak1.Func1 (1000); begin Pak2.Do_Something_With (Z); end Test1; When Z is initialized, 7.6(21) gives the implementation permission to have Func1 build its result directly in Z, without requiring an anonymous object; but this isn't a requirement. If the call to Func1 creates an anonymous object, then Adjust will be called on Z after this anonymous object is copied to Z, and then Finalize will be called on the anonymous object (presumably there would be a real Finalize that deallocates F3). If the implementation takes advantage of the permission, then it would seem the extended return statement would essentially be setting up Z.F1, Z.F2, and Z.F3. No Adjust would be necessary on Z, and an Adjust would not be desirable since it would result in two copies of the same string, one of which would not be part of any object of type Typ1 and thus would never be deallocated by Finalize. So it would seem that Adjust is not called at all by the declaration of Z. Am I right, that this is how things are "supposed" to work? In fact, this seems to be confirmed by AARM 7.6(2.b/2): "When an object is created, if it is explicitly assigned an initial value, the object is either built-in-place from an aggregate or function call (in which case neither Adjust nor Initialize is applied), or the assignment copies and adjusts the initial value." But 7.6(21.b/2) seems to directly contradict this. After mentioning the aggregate case in 21.a, 21.b says, "Similarly, in the function call case, the anonymous object can be eliminated. Note, however, that Adjust must be called directly on the target object as the last step of the assignment, since some of the subcomponents may be self-referential or otherwise position-dependent. This Adjust can be eliminated only by using one of the following permissions." (The "following permissions" refer to cases where a variable isn't actually used except by dead code, so they wouldn't apply in the above example.) This seems wrong. If I'm correct, then 7.6.1(24.c/2) is wrong also: "Either Initialize or Adjust, but not both, is applied to (almost) every controlled object when it is created: Initialize is done when no initial value is assigned to the object, whereas Adjust is done as part of assigning the initial value. The one exception is the anonymous object initialized created by an aggregate (both the anonymous object created for an aggregate, or an object initialized by an aggregate that is built-in-place); Initialize is not applied to the aggregate as a whole, nor is the value of the aggregate or object adjusted." since there are now two exceptions instead of one. I realize that this is probably low priority since it's "just" the AARM. But I do refer to the AARM, and I think it's important that the AARM not give bad information. **************************************************************** From: Randy Brukardt Sent: Wednesday, June 20, 2007 2:53 PM > There are a couple places in the AARM that I believe provide incorrect > information when dealing with a "built-in-place" function call. I saw > these when I was trying to figure out what would happen with an > extended return, and the information threw me off; it took some time > before I figured out that the AARM was probably incorrect. I don't think the AARM is incorrect, although it might not be clear as it could be. (That's true for the normative wording as well.) >Consider: > > with Ada.Finalization; > package Pak1 is > type String_Acc is access String; > type Typ1 is new Ada.Finalization.Controlled with record > F1 : Integer; > F2 : Integer; > F3 : String_Acc; > end record; >-- procedure Initialize (Obj : in out Typ1); > procedure Adjust (Obj : in out Typ1); >-- procedure Finalize (Obj : in out Typ1); > function Func1 (Val : Integer) return Typ1; > end Pak1; > > with Text_IO; > package body Pak1 is > > procedure Adjust (Obj : in out Typ1) is > begin > if Obj.F3 /= null then > Obj.F3 := new String' (Obj.F3.all); > end if; > end Adjust; > > function Func1 (Val : Integer) return Typ1 is > begin > return Ret : Typ1 do > Ret.F1 := Val * 2; > Ret.F2 := Val * 3; > Ret.F3 := new String' (1 .. Val => '?'); > end return; > end Func1; > > end Pak1; > > with Pak1; > procedure Test1 is > Z : Pak1.Typ1 := Pak1.Func1 (1000); > begin > Pak2.Do_Something_With (Z); > end Test1; > When Z is initialized, 7.6(21) gives the implementation permission to > have Func1 build its result directly in Z, without requiring an > anonymous object; but this isn't a requirement. If the call to Func1 > creates an anonymous object, then Adjust will be called on Z after > this anonymous object is copied to Z, and then Finalize will be called > on the anonymous object (presumably there would be a real Finalize > that deallocates F3). If the implementation takes advantage of the > permission, then it would seem the extended return statement would > essentially be setting up Z.F1, Z.F2, and Z.F3. No Adjust would be > necessary on Z, and an Adjust would not be desirable since it would > result in two copies of the same string, one of which would not be > part of any object of type Typ1 and thus would never be deallocated by > Finalize. So it would seem that Adjust is not called at all by the > declaration of Z. Am I right, that this is how things are "supposed" > to work? But you forgot to include a call to Initialize in your description. I see that you have Initialize commented out, but a null Initialize is still called. It's a mistake to ignore those null calls just because they have no effect, it is hard enough to figure out what is supposed to happen without leaving out part of the equation. The declaration of Ret : Typ1 in your example calls Initialize. (If that had been initialized with an aggregate, there would have been no call to Initialize, different story.) 6.5(5.8/2) says that the object is initialized by default, and that wording is a defined term which includes all of the stuff, including calling Initialize. The only thing that is a real rule is that only "pairs" of finalization operations are removed, so if a Finalize is removed, an Adjust is removed somewhere, too. (We didn't write it that way because there may be more than two operations in a "pair" if control flow intercedes, but at run time it is always a pair.) I do agree that Adjust isn't called by the declaration of Z, because Initialize is instead (and you never call them both on the same object for the same operation). > In fact, this seems to be confirmed by AARM 7.6(2.b/2): "When an > object is created, if it is explicitly assigned an initial value, the > object is either built-in-place from an aggregate or function call (in > which case neither Adjust nor Initialize is applied), or the > assignment copies and adjusts the initial value." > > But 7.6(21.b/2) seems to directly contradict this. After mentioning > the aggregate case in 21.a, 21.b says, "Similarly, in the function > call case, the anonymous object can be eliminated. Note, however, that > Adjust must be called directly on the target object as the last step > of the assignment, since some of the subcomponents may be > self-referential or otherwise position-dependent. This Adjust can be > eliminated only by using one of the following permissions." 7.6(21.b/2) is just a continuation of the Ada 95 note 7.6(21.a), and it says *exactly* the same thing (with more words). Clearly, if either are wrong, both are. In any case, it is clear that these are talking about assignments into existing objects (including those that were previously Initialized), and not build-in-place into new objects. (The later has completely different [null] semantics and can never be combined with any discussion of "real" assignment.) That's true in virtually every note in the AARM that talks about dynamic semantics of assignment; you don't "assign" into a new object, only into existing ones. Now, maybe there is some wording that could be added that would help clarify this, but it would have to be added in literally dozens of places, and in such a way that it would not make the information harder to understand (the point of AARM notes is to clarify, after all). > (The "following permissions" refer to cases where a variable isn't > actually used except by dead code, so they wouldn't apply in the above > example.) > > This seems wrong. > > If I'm correct, then 7.6.1(24.c/2) is wrong also: > > "Either Initialize or Adjust, but not both, is applied to (almost) > every controlled object when it is created: Initialize is done when no > initial value is assigned to the object, whereas Adjust is done as > part of assigning the initial value. The one exception is the > anonymous object initialized created by an aggregate (both the > anonymous object created for an aggregate, or an object initialized by > an aggregate that is built-in-place); Initialize is not applied to the > aggregate as a whole, nor is the value of the aggregate or object > adjusted." > > since there are now two exceptions instead of one. No, this is correct as written. There may be intermediate function calls, but they're irrelevant. Ultimately, you either get initialized directly by an aggregate, or Initialize is called. In your example, Initialize is called. So I don't see any other exceptions. > I realize that this is probably low priority since it's "just" the > AARM. But I do refer to the AARM, and I think it's important that the > AARM not give bad information. It's low priority because not much (if anything) is wrong. It looks like you're just confused about where Initialize is called. The only reason I see for making a change is that you were confused, and that always suggests that things aren't as clear as they should be somewhere. **************************************************************** From: Tucker Taft Sent: Wednesday, June 20, 2007 2:52 PM I believe what is misleading about 7.6(21.b/2) is that it only applies to assignment_statement, while it uses the term "assignment." The wording it replaced properly used the term "assignment_statement," and I think that term should continue to be used in the revised wording. I don't see what is wrong with 7.6.1(24.c/2), since I believe the only case where Adjust is not called is when, at least "deep down," there is an aggregate. It might be returned through several function calls that use build-in-place for return, but underneath it all there needs to be an aggregate. It could probably be a bit clearer, I suppose, about the possibility of intervening function returns. **************************************************************** From: Adam Beneschan Sent: Wednesday, June 20, 2007 4:18 PM > > When Z is initialized, 7.6(21) gives the implementation permission to > > have Func1 build its result directly in Z, without requiring an > > anonymous object; but this isn't a requirement. If the call to Func1 > > creates an anonymous object, then Adjust will be called on Z after > > this anonymous object is copied to Z, and then Finalize will be called > > on the anonymous object (presumably there would be a real Finalize > > that deallocates F3). If the implementation takes advantage of the > > permission, then it would seem the extended return statement would > > essentially be setting up Z.F1, Z.F2, and Z.F3. No Adjust would be > > necessary on Z, and an Adjust would not be desirable since it would > > result in two copies of the same string, one of which would not be > > part of any object of type Typ1 and thus would never be deallocated by > > Finalize. So it would seem that Adjust is not called at all by the > > declaration of Z. Am I right, that this is how things are "supposed" > > to work? > > But you forgot to include a call to Initialize in your > description.... Right, I could have been more precise about that. I really didn't see that it made a difference, though, since the AARM paragraph I was questioning made no reference to Initializing. OK, now I see how this affects the *second* one I was complaining about (7.6(24.c/2)). > 7.6(21.b/2) is just a continuation of the Ada 95 note 7.6(21.a), and it says > *exactly* the same thing (with more words). Clearly, if either are wrong, > both are. Interesting---I didn't see it that way at all when I read it. The way the paragraph breaks are organized, it made it look like the part of 7.6(21.b/2) after the first sentence applied only to this paragraph, not to the previous one. > In any case, it is clear that these are talking about assignments into > existing objects (including those that were previously Initialized), and not > build-in-place into new objects. Why is this clear? The notes 7.6(21.a-21.b) follow, and seem to apply to, 7.6(21), which talks *both* about build-in-place for new objects *and* assignment statements; I don't see anything in the text that would indicate that 21.a-21.b apply to the assignment-statement part of 21 but not to the build-in-place-for-new-objects part. I think Tuck already addressed this... the previous version of 21.b referred to an "assignment_statement", which would have made things clearer in the rest of the paragraph, but that reference got deleted. > (The later has completely different [null] > semantics and can never be combined with any discussion of "real" > assignment.) That's true in virtually every note in the AARM that talks > about dynamic semantics of assignment; you don't "assign" into a new object, > only into existing ones. Well, I was going to respond that 3.3.1(19) used the term "assigned" to put an initial value into a new object. But now I notice that this language got moved up to the preceding paragraph which only applies to objects with no initialization expression. So I guess that change made your statement correct. :) There's still 7.6(13): "When a target object with any controlled parts is assigned a value, either when created or in a subsequent assignment_statement, the assignment operation proceeds as follows:" which does make it seem that you *do* assign into a new object. But I guess you could say this is only the case if the Implementation Permission (or Implementation Requirement, for limited types) not to create a temporary anonymous object is followed, in which case 7.6(15) of course does not apply either. It appears to me that the whole build-in-place concept seems to make some statements in the Dynamic Semantics sections false, which suggests to me that it should have been defined and dealt with in Dynamic Semantics rather than in Implementation Requirements/Permissions, but it's probably too late to change that now. > > If I'm correct, then 7.6.1(24.c/2) is wrong also: > > > > "Either Initialize or Adjust, but not both, is applied to (almost) > > every controlled object when it is created: Initialize is done when no > > initial value is assigned to the object, whereas Adjust is done as > > part of assigning the initial value. The one exception is the > > anonymous object initialized created by an aggregate (both the > > anonymous object created for an aggregate, or an object initialized by > > an aggregate that is built-in-place); Initialize is not applied to the > > aggregate as a whole, nor is the value of the aggregate or object > > adjusted." > > > > since there are now two exceptions instead of one. > > No, this is correct as written. There may be intermediate function calls, > but they're irrelevant. Ultimately, you either get initialized directly by > an aggregate, or Initialize is called. In your example, Initialize is > called. So I don't see any other exceptions. Yeah, I'll concede this... I forgot about the Initialize on Ret. **************************************************************** From: Randy Brukardt Sent: Wednesday, June 20, 2007 5:48 PM > I believe what is misleading about 7.6(21.b/2) is > that it only applies to assignment_statement, while > it uses the term "assignment." The wording it replaced > properly used the term "assignment_statement," and > I think that term should continue to be used in the revised > wording. But that would be wrong, because it equally applies to initial assignments where an anonymous object was used (as Adam pointed out in his analysis). Also, whatever applies here also applies to 7.6(21.a), which talks about a "value adjustment". One way to fix this would be to rewrite both paragraphs to make clear that they do not apply to "build-in-place assignment to a newly created object", but it's not clear to me that that would help the understandability of it. Realistically, build-in-place is not really assignment at all (no bits are copied), and considering it that is really confusing. I suppose we don't have any hope of fixing that directly, but maybe we could at least do something to make sense for the notes. Maybe we need to define "genuine assignment" for use in the AARM to describe cases where bits are actually copied. (I'd prefer "real assignment" for that, but that could be confused.) **************************************************************** From: Randy Brukardt Sent: Wednesday, June 20, 2007 6:04 PM ... > > 7.6(21.b/2) is just a continuation of the Ada 95 note > 7.6(21.a), and it says > > *exactly* the same thing (with more words). Clearly, if either > are wrong, > > both are. > > Interesting---I didn't see it that way at all when I read it. The way > the paragraph breaks are organized, it made it look like the part of > 7.6(21.b/2) after the first sentence applied only to this paragraph, > not to the previous one. They were originally separate paragraphs, but there really is no interesting difference between then and they should not really be separate. You have to do an adjust anytime that you copy bits. > > In any case, it is clear that these are talking about assignments into > > existing objects (including those that were previously Initialized), and not > > build-in-place into new objects. > > Why is this clear? Because it's clear to me, and I wrote these notes. ;-) As I wrote in response to Tucker, build-in-place is a different animal altogether, and describing it as an assignment is very confusing to the casual reader. Or even the casual (or rushed) writer. > The notes 7.6(21.a-21.b) follow, and seem to apply > to, 7.6(21), which talks *both* about build-in-place for new objects > *and* assignment statements; I don't see anything in the text that > would indicate that 21.a-21.b apply to the assignment-statement part > of 21 but not to the build-in-place-for-new-objects part. I think > Tuck already addressed this... the previous version of 21.b referred > to an "assignment_statement", which would have made things clearer in > the rest of the paragraph, but that reference got deleted. I as I mentioned to Tuck, that would be wrong. OK, it would be right but it would make the note far more narrow than it should be. Both notes apply anytime bits are copied (but not build-in-place). I suppose trying to fix these notes rather than deleting them and starting over got me into trouble. It happens a lot in the AARM. In any case, the note had better be true whenever there is a copying of bits, because packages like Claw depend totally on that. Not just in assignment_statement, but anywhere that bits are copied. You don't need an Adjust for build-in-place, because no bits are being copied and presumably the object was properly created (most likely with an Initialize) in the first place. > > (The later has completely different [null] > > semantics and can never be combined with any discussion of "real" > > assignment.) That's true in virtually every note in the AARM that talks > > about dynamic semantics of assignment; you don't "assign" into a new object, > > only into existing ones. ... > There's still 7.6(13): > > "When a target object with any controlled parts is assigned a value, > either when created or in a subsequent assignment_statement, the > assignment operation proceeds as follows:" > > which does make it seem that you *do* assign into a new object. You misunderstood me. I said *in notes* of the AARM, I was *not* talking about the formal definition of the language. Yes, of course build-in-place is technically assignment. *Informal* uses generally *exclude* build-in-place because no bits are copied, no finalization operations happen, etc. -- it's generally not interesting. Would you (if you were not language lawyering) consider build-in-place to be an assignment? If so, I think you're pretty unusual. It's highly unfortunate that the useful term "assignment" has been corrupted by the language into something meaningless, but I guess that can't be helped. But I doubt that there are many AARM notes that I wrote or that the Ada 9x team wrote that consider (or except) the vastly different rules for build-in-place. So it would not surprise me if you found many more examples where notes don't take that into account. If you find them, I'll put them on the list to be fixed. But I still not sure of an appropriate fix that doesn't greatly confuse the issue. **************************************************************** From: Adam Beneschan Sent: Wednesday, June 20, 2007 6:17 PM > You misunderstood me. I said *in notes* of the AARM, I was *not* talking > about the formal definition of the language. Yes, of course build-in-place > is technically assignment. > *Informal* uses generally *exclude* build-in-place because no bits are > copied, no finalization operations happen, etc. -- it's generally not > interesting. Would you (if you were not language lawyering) consider > build-in-place to be an assignment? If so, I think you're pretty unusual. Well, you're probably right. But not *that* unusual. :) No, I wouldn't consider that to be assignment---but I do tend to look through language-lawyer eyes when trying to figure out what the standard requires, which is approximately the same problem I had when trying to figure out when an extended return is "completed". > It's highly unfortunate that the useful term "assignment" has been corrupted > by the language into something meaningless, but I guess that can't be > helped. But I doubt that there are many AARM notes that I wrote or that the > Ada 9x team wrote that consider (or except) the vastly different rules for > build-in-place. So it would not surprise me if you found many more examples > where notes don't take that into account. > > If you find them, I'll put them on the list to be fixed. But I still not > sure of an appropriate fix that doesn't greatly confuse the issue. Perhaps the best fix would be: "An implementation is permitted to omit the separate anonymous object for an aggregate or function call, and to omit Initialize, Adjust, and Finalize calls, when it can do so and still make things work right." Not very precise, but at least it wouldn't be confusing. :) **************************************************************** From: Randy Brukardt Sent: Wednesday, June 20, 2007 6:45 PM I take it you are suggesting that there be no notes at all? (Useless notes like this one add nothing to the language-defined permission, after all.) That surely would be one solution to the confusion. BTW, your suggested wording is very close to something someone else proposed a couple of months ago (for a different but related issue). I think it captures the essence nicely, but of course it is completely meaningless (what does "work right" mean?). **************************************************************** From: Tucker Taft Sent: Wednesday, June 20, 2007 11:45 PM >> I believe what is misleading about 7.6(21.b/2) is >> that it only applies to assignment_statement, while >> it uses the term "assignment." The wording it replaced >> properly used the term "assignment_statement," and >> I think that term should continue to be used in the revised >> wording. > > But that would be wrong, because it equally applies to initial assignments > where an anonymous object was used (as Adam pointed out in his analysis). > Also, whatever applies here also applies to 7.6(21.a), which talks about a > "value adjustment". I still don't agree. The last sentence of 7.6(21.b/2) is referring to an assignment statement based on my reading. 7.6(21/2) talks about two things. One is build-in-place when the RHS is an aggregate or function call. The other is about an assignment statement where the RHS is non-overlapping, or the assignment is done component-at-a-time (carefully). I believe the last sentence of 7.6(21.b/2) is referring to this last part of 7.6(21/2), which is specifically talking about assignment statements. The whole point of the last sentence of 7.6(21.b/2) is that you cannot eliminate the Adjust, even if you eliminate the anonymous intermediate object. On the other hand, it is no problem to eliminate the Adjust when doing build-in-place where the RHS is an aggregate, and in fact it would be wrong to do an Adjust for any build-in-place assignment from an aggregate. For what it is worth, I find the *first* sentence of 7.6(21.b/2) to be curious, as it seems to be repeating the content of the first sentence of 7.6(21/2), and I think may be an unintentional remnant, and should be deleted. Otherwise, someone needs to explain what "function call" it is referring to, if not to the one already mentioned in the first part of 7.6(21/2). > > One way to fix this would be to rewrite both paragraphs to make clear that > they do not apply to "build-in-place assignment to a newly created object", > but it's not clear to me that that would help the understandability of it. You seem to be implying that build-in-place on a preexisting object in an assignment statement requires an Adjust. I don't understand that. I think build-in-place eliminates the need for Adjust, both when creating a new object and when assigning to a preexisting object. If there is no separate object that is going to be finalized after the adjust, then we don't want to do the adjust. One challenge is that I don't believe it is really feasible to do build-in-place for an assignment *statement* when the RHS is a function call, since you clearly need to evaluate the RHS before finalizing the LHS, but you must finalize the LHS before changing it. So build-in-place for an assignment *statement* really only works if you can evaluate all of the subcomponents of the aggregate *without* storing them in the target object, then finalize the target object, and then (with aborts deferred) assign each of the subcomponents into the LHS. I believe you need to defer aborts since you don't want a Finalize to be applied to the LHS when is in the middle of being overwritten. But in any case, you don't want to call Adjust if you build-in-place. Adjust really only makes sense if you are copying the bits of a fully-formed object into another location. I believe that is what 7.6(17.1/2) is saying. Even though the requirement to build-in-place only exists for assignments which are *not* part of an assignment statement, I believe the *meaning* of build-in-place and the requirement to *omit* the Adjust is provided by 7.6(17.1/2), and then applies to the use of the term in 7.6(21/2). It would be weird if you would have to use slightly different aggregates depending on whether you were assigning to a newly created object versus a pre-existing object. In both cases you want the aggregates to represent fully adjusted values. For example, if an adjust increments a reference count for a pointed-to object, and finalize decrements the reference count, the aggregate would want to initialize the reference count of the pointed-to object to "1". E.g. (x, y, new indir_obj'(ref_count => 1, ...), z) would be the appropriate way to write an aggregate for such a type, no matter in what context it is used. I am coming around to thinking that the AARM notes following 7.6(21/2) are pretty badly broken. I would recommend we make them simpler and clearer, perhaps as follows: Replace 7.6(21.a & b) with: Ramification: Note that in the second case, where the anonymous object is eliminated but the new value is not created directly in the target object, Adjust must be called directly on the target object as the last step of the assignment, since some of the subcomponents may be self-referential or otherwise position- dependent. This Adjust can be eliminated only by using one of the following permissions. **************************************************************** From: Randy Brukardt Sent: Thursday, June 21, 2007 12:38 AM > I still don't agree. The last sentence of 7.6(21.b/2) > is referring to an assignment statement based on > my reading. 7.6(21/2) talks about two things. One > is build-in-place when the RHS is an aggregate or > function call. The other is about an assignment > statement where the RHS is non-overlapping, or > the assignment is done component-at-a-time (carefully). > I believe the last sentence of 7.6(21.b/2) is referring > to this last part of 7.6(21/2), which is specifically > talking about assignment statements. The whole point > of the last sentence of 7.6(21.b/2) is that you cannot > eliminate the Adjust, even if you eliminate the anonymous > intermediate object. On the other hand, it is no > problem to eliminate the Adjust when doing build-in-place > where the RHS is an aggregate, and in fact it would > be wrong to do an Adjust for any build-in-place > assignment from an aggregate. Why do you never, even comment on 7.6(21.a)? What possible value adjustment is there in a build-in-place initialization by an aggregate??? Anyway, I can't believe that you are telling me, the author of the sentence in question what it means. I *know* what it means; maybe what I intended isn't right, but I deleted the "assignment_statement" from 7.6(21.b/2) on purpose because this (I think) covers more than just assignment statements. It applies any time bits of the entire cbject are copied as part of an assignment operation, no matter what permissions are applied -- as long as there still is an overall bit copy of the whole object (not just individual components). Now I see you are trying to tie it solely to 7.6(21/2), but I often try to make generally useful statements: there is always an Adjust. ... > For what it is worth, I find the *first* sentence of 7.6(21.b/2) > to be curious, as it seems to be repeating the content of > the first sentence of 7.6(21/2), and I think may be an > unintentional remnant, and should be deleted. Otherwise, > someone needs to explain what "function call" it is > referring to, if not to the one already mentioned in > the first part of 7.6(21/2). I put it there to set the stage for the rest of it. If it just followed a paragraph about aggregates, the reader would reasonably think that we were only talking about aggregates in 7.6(21.b/2). Feel free to suggest something better. > > One way to fix this would be to rewrite both paragraphs to make clear that > > they do not apply to "build-in-place assignment to a newly created object", > > but it's not clear to me that that would help the understandability of it. > > You seem to be implying that build-in-place on a preexisting object > in an assignment statement requires an Adjust. I don't think that there can be any such thing, at least if there is a non-trivial Adjust. Otherwise, the model of 0 or 1 Initialize followed by (Finalize/Adjust) followed by Finalize no longer works (you have objects that are potentially Initialized multiple times). > I don't understand > that. I think build-in-place eliminates the need for Adjust, > both when creating a new object and when assigning to a > preexisting object. If there is no separate object that is going to > be finalized after the adjust, then we don't want to do the adjust. I don't see how you can "build-in-place" self-referencing pointers properly. (Especially now that we know return objects aren't aliased; you can't even write such a thing.) If you can prove that they don't exist, you can remove the Adjust, but only then. > One challenge is that I don't believe it is really feasible > to do build-in-place for an assignment *statement* when the RHS is > a function call, since you clearly need to evaluate the > RHS before finalizing the LHS, but you must finalize the LHS > before changing it. So build-in-place for an assignment *statement* > really only works if you can evaluate all of the subcomponents > of the aggregate *without* storing them in the target object, > then finalize the target object, and then (with aborts deferred) > assign each of the subcomponents into the LHS. I believe > you need to defer aborts since you don't want a Finalize > to be applied to the LHS when is in the middle of being > overwritten. Exactly; it's impractical, if not impossible (I think it is impossible). > But in any case, you don't want to call Adjust > if you build-in-place. Adjust really only makes sense if you > are copying the bits of a fully-formed object into another > location. I believe that is what 7.6(17.1/2) is saying. Even though > the requirement to build-in-place only exists for assignments > which are *not* part of an assignment statement, I believe the > *meaning* of build-in-place and the requirement to *omit* the > Adjust is provided by 7.6(17.1/2), and then applies to the > use of the term in 7.6(21/2). But 7.6(17.1/2 explicitly excludes assignment_statement; surely it doesn't apply to them. > It would be weird if you would have to use > slightly different aggregates depending on > whether you were assigning to a newly created object versus > a pre-existing object. You do, because you have to do *assignment* differently for each. I can't imagine how build-in-place would suddenly change that dynamic. One obvious requirement is to allocate the memory for sub-components (which only happens with a new object). What the user writes may be the same, but what the compiler generates is quite different for the two cases. Build-in-place is impractical in general for non-limited types (of course it can be used on types with no controlled or discriminant-dependent components). ... > I am coming around to thinking that the AARM notes following > 7.6(21/2) are pretty badly broken. Apparently because the model I have of Finalization isn't the same as yours. We're going to need to reconcile that... At least you decided to mention 7.6(21.a) finally. > I would recommend > we make them simpler and clearer, perhaps as follows: > > Replace 7.6(21.a & b) with: > > Ramification: Note that in the second case, What second case? That's way too vague (I don't see any obvious "second case" in 7.6(21/2)). > ... where the anonymous > object is eliminated but the new value is not created directly > in the target object, Adjust must be called directly on the target > object as the last step of the assignment, since some of the > subcomponents may be self-referential or otherwise position- > dependent. This Adjust can be eliminated only by using one > of the following permissions. That's OK and I suppose we can agree on this in the sense that it is very limited in scope. (And it mainly is intended to tell implementers not to make the optimization that the early Intermetrics compilers did.) I do think that you'll find similar problems in other notes in the manual. I don't think we think about build-in-place ever when thinking about assignment, and it really is not an assignment. But one problem at a time... **************************************************************** From: Randy Brukardt Sent: Friday, August 3, 2007 10:10 PM AARM "To Be Honest" notes should be added to 6.6(2) and possibly 6.4(3) to make it clear that "function_call" includes infix operator calls when it is used in RM rules other than syntax definitions. (There are at least 7 rules and many AARM notes which use "function_call" this way.) See AC-00143 for a full discussion. **************************************************************** From: Randy Brukardt Sent: Wednesday, September 5, 2007 11:38 PM I was fixing 7.6(16) as we discussed before I left on my ill-fated vacation, and I got to reading 7.6(16.b): Reason: The verbiage in the Initialize rule about access discriminants constrained by per-object expressions is not necessary here, since such types are limited, and therefore are never adjusted. ["here" being the definition of "adjustment".] This looks like it is no longer true, as we surely can have access discriminants of nonlimited types these days. The "verbiage" in question gives a required order for operations. Do we need such an order? I don't think so, because an Adjust can't change the discriminant values of an object (only the assignment of the bits can do that). So I think that the reason above should say that and not depend on limited types. But if I forgot some case where an ordering is required, then we probably need an AI. Any idea if it is needed and if so, what it should say?? **************************************************************** From: Tucker Taft Sent: Thursday, September 6, 2007 2:13 AM You can't give defaults to access discriminants in a non-limited type (3.7(10/2)). This means access discriminants never change after creation, and in particular can't be changed in an Adjust. **************************************************************** From: Randy Brukardt Sent: Thursday, September 6, 2007 9:45 PM Humm, I think we intended that, but I don't think it is actually true in *every* case. The rule about defaults does not apply to discriminants that have a named access type, so I think you could have a changeable per-object access discriminant. Making my best Steve Baird impression, consider the following: type Comp_Type (CD : access Integer) is record ... end record; type Acc_Int is access all Integer; One : constant aliased Integer := 1; Two : constant aliased Integer := 2; type Obj_Type (D : Acc_Int := One'access) is record Comp : Comp_Type (D); end record; Obj : Obj_Type; Obj2 : Obj_Type (Two'access); Obj := Obj2; -- Seems to change the discriminant of Comp. The discriminant D of Obj_Type is not an access discriminant, so 3.7(10/2) does not apply and it can have a default. D then is then used as a per-object constraint for Comp. When the assignment happens, D goes from One'access to Two'access, and surely the discriminant of Comp does too. This construct seems to not cause the problems that we fixed by dropping the discriminant default, because the accessibility check that was needed on the assignment is going to be done by the conversion to the named type of the outer discriminant. Consider: procedure Fooey is Three : constant aliased Integer := 3; Obj3 : Obj_Type (Three'access); -- Error: Accessibility check fails. begin Obj := Obj3; -- Which is good 'cause we sure wouldn't want to allow this. end Fooey; The net seems to be that you can change an access discriminant in very restricted circumstances, as there is no reason to disallow it. So the question remains: does this matter for Adjust? Initialize specifies that per-object constrained components are done last. But I can't think of a way where it might matter where they are done for adjustment, because an Adjust of a component cannot change the discriminant of the per-object constrained component; only the outer assignment can do that. And there is a requirement that inner (component) Adjusts be done first, so a surrounding one that changed such a discriminant would necessarily happen after any component Adjusts were completed, eliminating any issue. So 7.6(16.b) should just be fixed. **************************************************************** From: Tucker Taft Sent: Friday, September 7, 2007 7:23 AM My head hurts... ;-) Interesting example. It is generally true that by changing the discriminant of an object in a whole-object assignment you can do all kinds of violence to its components, including having them disappear or appear (if the component is in a discriminant-dependent variant), get shorter or longer, etc. I guess we need to add that you can change the value of an access discriminant of a component as another kind of violence. I'm pretty sure we *did* include the case of an access discriminant initialized from an enclosing discriminant when we analyzed the safety of allowing access discriminants on nonlimited types. On the other hand, I don't remember considering this particular nastiness, and I am comforted that you see no accessibility holes opening as part of the enclosing assignment. In some ways, when doing a whole-object assignment that changes discriminants, one might best view it as destroying one object and creating a new one. And in fact, since Finalize is applied to the left hand side, and then it is completely overwritten followed by an Adjust, it closely resembles the process of destruction and recreation. On the other hand, renames of components and access-values designating components are permitted to survive across these "mutating" assignments so long as the components aren't "discriminant dependent." Any component whose access discriminant comes from an enclosing discriminant is clearly discriminant dependent, so we that means we *can* think of the component as disappearing and then reappearing with a new discriminant value after the assignment. I suppose if it is a subcomponent but not a direct component, then it is possible that the Adjust might involve another whole-object assignment to an enclosing component. E.g. procedure Adjust(X : in out Outer_Rec) is begin X.Go_Between := Massage(X.Go_Between); -- Presume our subcomponent of interest is -- inside "Go_Between" and has an access discrim -- passed down from the "Go_Between" component -- This could change its discriminant again. end Adjust; Note that it would be quite unwise if Outer_Rec's Adjust involved a whole-object assignment to X itself; e.g.: X := Massage_Outer_Rec(X); as this would trigger an infinitely recursive call on Outer_Rec's Adjust. I've reached the point of blathering... ;-) In any case, thanks for doing the analysis of this nasty case. **************************************************************** !topic AARM refers to return-by-reference types !reference AARM 6.2(11.a) !from Adam Beneschan 07-10-29 !discussion Small nit: AARM 6.2(11.a) contains a couple of references to return-by-reference types, which don't exist any more. The paragraph should probably be rewritten. **************************************************************** !topic universal_access not in index !reference RM05 index !from Adam Beneschan 07-11-06 !discussion A very minor issue: In the index (at least the one available at http://www.adaic.org/standards/05aarm/html/AA-0-5.html), there are entries for universal_integer, universal_real, and universal_fixed, but not universal_access. It seems that it should be there for consistency/completeness. **************************************************************** From the minutes of the 33rd ARG meeting: In unrelated news, Tucker says that "needs finalization" needs more index entries. Specifically, there should be an index entry for each standard type defined to "need finalization". **************************************************************** !topic Missed '|' in formal_object_declaration syntax !reference Ada 2005 RM 12.4(2/2) !from Maxim Reznik 07-12-27 !keywords formal_object_declaration !discussion Alternative separator '|' is missed in syntax rule for formal_object_declaration. Should be: formal_object_declaration ::= defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]; | defining_identifier_list : mode access_definition [:= default_expression]; [Editor's note: This error occurs only in the Ada Europe consolidated RM; it is correct in the Amendment document, which is the official standard. Thus, this is recorded here.] **************************************************************** From: John Barnes Sent: Friday, December 28, 2007 12:10 PM It's like it in Annex P as well. (But my book is OK). Happy New Year **************************************************************** From: Tucker Taft Sent: Wednesday, March 26, 2008 3:29 PM In an AARM annotation (13.13.1(9.b/2), we indicate that it is unwise to use Stream_Element_Offset'First as the low bound for the Item passed to a stream Read procedure, because you will get a Constraint_Error if the stream is empty. We then go on to say that a better choice of lower bound is 1. But earlier we indicate that either 0 or 1 makes sense, and this last bit of advice will probably make the reader think that Stream_Element_Offset'First = 0, when in fact it is probably -Stream_Element_Offset'Last-1. Here is my suggested minor presentation fix: This implies that the Stream_Element_Array passed to these subprograms should not have a lower bound of Stream_Element_Offset'First, because then a read of 0 elements would always raise Constraint_Error. A better choice of lower bound is {0 or} 1. I am suggesting this fix because I read the original wording several times, and then stared at the Streams package, and had to work hard to assure myself that Stream_Element_Offset'First was not zero. If it had said "0 or 1" to begin with, I would have understood it immediately. **************************************************************** From: Adam Beneschan Sent: Monday, April 28, 2008 12:37 PM The term "mentioned" has a specific definition in 10.2.1(6), but it is not in the correct place in index at: http://www.adaic.org/standards/05aarm/html/AA-0-5.html It looks like it's supposed to be there but somehow got stuck under T: Term=[mentioned],Sec=[in a with_clause] 10.1.2(6/2) **************************************************************** !topic universal_access is not in the index !reference 3.4.1(6) !from Adam Beneschan 08-06-05 !discussion Presentation issue: 3.4.1(6) says, "Universal types are defined for (and belong to) the integer, real, and fixed point, and access classes, and are referred to in this standard as respectively, universal_integer, universal_real, universal_fixed, and universal_access. universal_integer, universal_real, and universal_fixed are all listed in the index, but universal_access is not. This is a problem, since I was planning to look in the RM to find out what the semantic ramifications of "universal_access" are, but the index doesn't tell me where any discussions of this might be. Specifically, I'd hope that the index entry for universal_access (assuming it does get added) should refer to 4.5.2(7.2) and/or 4.5.2(9.1). **************************************************************** From: Randy Brukardt Sent: Thursday, June 12, 2008 12:11 AM !topic universal_access is not in the index ... Is this the dept. of redundancy department?? Some guy by the name of Adam Beneschan sent the following to this very list on November 6th, 2007: !topic universal_access not in index !reference RM05 index !from Adam Beneschan 07-11-06 !discussion A very minor issue: In the index (at least the one available at http://www.adaic.org/standards/05aarm/html/AA-0-5.html), there are entries for universal_integer, universal_real, and universal_fixed, but not universal_access. It seems that it should be there for consistency/completeness. --- Let me make a couple of other points: The index is not technically part of the standard. So suggestions for the index are handled like AARM comments, and attached to AI05-0005-1. Moreover, I generally make those to the working version of the Standard immediately (like all AARM comments). So this was all handled back in November. Looking all of this up has wasted quite a bit of time, unfortunately. > Specifically, I'd hope that the index entry for universal_access > (assuming it does get added) > should refer to 4.5.2(7.2) and/or 4.5.2(9.1). That would be inconsistent with the rest of the standard, for which we only index definitions, not uses. If we were to start indexing uses, there are many, many places where such indexes would be valuable (and that would imply a *lot* of work). For instance, I would like to see a list of all of the places where predefined routines raise (specific) exceptions (we do index language-defined checks). Most importantly, we'd want "definition" index entries to look different somehow than "use" index entries, which implies new commands and formatting for the formatting tool. A very slippery slope. **************************************************************** From: Adam Beneschan Sent: Thursday, June 12, 2008 11:06 AM > !topic universal_access is not in the index ... > > Is this the dept. of redundancy department?? Yes, and yes. :-) > Some guy by the name of Adam > Beneschan sent the following to this very list on November 6th, 2007: > > !topic universal_access not in index > !reference RM05 index > !from Adam Beneschan 07-11-06 > !discussion > > A very minor issue: In the index (at least the one available at > http://www.adaic.org/standards/05aarm/html/AA-0-5.html), there are > entries for universal_integer, universal_real, and universal_fixed, > but not universal_access. It seems that it should be there for > consistency/completeness. Yep. I had completely forgotten that I had sent this earlier. > Let me make a couple of other points: > > The index is not technically part of the standard. So suggestions for > the index are handled like AARM comments, and attached to AI05-0005-1. I wasn't aware of that. I did look at the AI05's to see if this issue had been submitted already, whether by people with names identical to mine or not, but it didn't occur to me to look at this particular one since nothing about the title made it seem relevant. Thanks for the info---I'll try to remember this next time. > Moreover, > I generally make those to the working version of the Standard > immediately (like all AARM comments). So this was all handled back in > November. Looking all of this up has wasted quite a bit of time, unfortunately. The version I use (noted above) doesn't have this change. Is the working version of the Standard available online? If so, I can check that first to help make sure I don't submit more redundant comments. My apologies for making you look this up unnecessarily. **************************************************************** From: Randy Brukardt Sent: Thursday, June 12, 2008 12:55 PM > The version I use (noted above) doesn't have this change. Is the > working version of the Standard available online? If so, I can check > that first to help make sure I don't submit more redundant comments. The super secret working version is not available to the public. The reason is that WG 9 has not decided on any plan for future work on the Ada standard, and for me and/or the ARG to make a working document available makes it appear that they have. (The changes are identified as belonging to "Corrigendum 2", a document that does not exist and may never exist.) It would be nice to let you have access to it (it is useful for the very reason that you note -- there are already too many approved AI05s to remember them all), but my hands are tied. **************************************************************** !topic Clarification requested on Wide_Bounded_IO definition !reference A.11(4), A.10.11(3) !from Adam Beneschan 08-06-11 !discussion A.11(4) says, when describing how to create the definition of Wide_Bounded_IO in terms of the Bounded_IO definition: any occurrence of package Bounded is replaced by Wide_Bounded. Does this refer only to the "Bounded" package defined as a child of Ada.Strings, or does it also refer to the generic formal package that is a parameter of the generic Ada.Text_IO.Bounded_IO? I suspect the answer is that it refers to both, but I think it's not 100% clear, and a clarification one way or the other would be useful. **************************************************************** !topic Ungrammatical sentence in AARM !reference Ada 2005 AARM 13.7.2(5.a/2) !from Christoph Grein 2008-06-17 !discussion The following sentence in parentheses, a quote from the paragraph cited above, does not make sense. Perhaps with the changes indicated, this is what is meant. (If Object is not a [not] by-reference type, the object ought to be aliased; recall that the Address attribute is not required to provide a useful result {for} other objects.) **************************************************************** !topic 12.4 presentation nitpick !reference RM05 12.4(2/2) !from Adam Beneschan 08-09-11 !discussion In 12.4(2/2), there should be a vertical bar somewhere separating the two different syntaxes for the generic formal object definition, but it seems to be missing. (It was present in the AI-423 text.) It is missing on both web pages: http://www.adaic.org/standards/05rm/html/RM-12-4.html http://www.adaic.org/standards/05aarm/html/AA-12-4.html **************************************************************** From: Randy Brukardt Sent: Thursday, September 25, 2008 12:55 PM It's correct in the actual Amendment document, so this is just a bug in the unofficial consolidated versions. As such, this isn't a change that needs to go through the ARG. Moreover, it was already noted here (Ada-Comment) in December (not that you or anyone else could be expected to remember that). **************************************************************** !topic Definition of "assignment operation" !reference 7.6(13-15), 7.6(21), 9.8(11) !from Adam Beneschan 08-09-24 !discussion When an assignment statement has a target that is a variable V of a controlled type, V is finalized, then the new value is copied into V, then V is adjusted. However, according to 7.6(13-15), only the last two steps of this process are considered an "assignment operation". When possibly overlapping slices are copied, the implementation permission in 7.6(21) allows this to take place one component at a time. This would mean, that for a case like A (N1 .. N2) := A (N3 .. N4); where A's element type is controlled or has controlled subcomponents, then the operations could be implemented as Finalize A(N1), copy into A(N1), adjust A(N1) Finalize A(N1+1), copy into A(N1+1), adjust A(N1+1), etc. or Finalize A(N2), copy into A(N2), adjust A(N2) Finalize A(N2-1), copy into A(N2-1), adjust A(N2-1), etc. where the order (forward or reverse) would be determined at runtime. How many "assignment operations" does this involve? If the Implementation Permission were not used, I think there would be just two assignment operations: *** START OF ASSIGNMENT OPERATION 1 *** Copy into anonymous object Adjust anonymous object *** END OF ASSIGNMENT OPERATION 1 *** Finalize A(N1..N2) *** START OF ASSIGNMENT OPERATION 2 *** Copy A(N1..N2) from anonymous object Adjust A(N1..N2) *** END OF ASSIGNMENT OPERATION 2 *** Finalize anonymous object But when an anonymous object isn't used, it's not clear to me how many assignment operations there are. Is the whole loop just one big assignment operation, or is there one assignment operation for each component? The reason this matters (somewhat) is because of 9.8(11). The question, of course, is: if the Implementation Permission of 7.6(21) is used in an overlapping slice case, at what points in the loop is an abort allowed to take place? I'm not sure the RM answers this question. **************************************************************** From: Tucker Taft Sent: Wednesday, September 24, 2008 7:33 PM If you take advantage of 7.6(20), then each subcomponent assignment can be separate, and the abort deferral only applies to the copy-and-adjust combination for that particular subcomponent. You would allow aborts between individual components. The only reason to defer abort is that you don't want the copy step separated from the adjust step. I believe the RM is relatively clear in 7.6(20) when it says: ... the implementation may finalize and assign each component of the variable separately ... I agree the wording in 7.6(21) which refers to 7.6(20) muddies the waters a bit. In any case, it wouldn't hurt to have an AARM note to emphasize that abort deferral needs to last only across an individual component assignment, and aborts can be handled between component assignments. **************************************************************** From: Christoph Grein Sent: Thursday, November 13, 2008 5:19 AM I could not find the policy identifiers FIFO_Within_Priorities etc in the RM index. So there is no place where you can find all predefined policies in one list. I would propose to enter them under "locking policy" in the index. **************************************************************** From: Adam Beneschan Sent: Thursday, November 13, 2008 12:47 PM I think you meant "task dispatching policy"? Lots of predefined identifiers occur in two places, e.g. language-defined pragmas and attributes appear both as themselves and under the "predefined" or "attribute" index entries respectively. That probably ought to be the case here, too. For one thing, having the identifier findable under its own name would help in a case where someone tries to find a task dispatching policy name in the "locking policy" index entry and can't find it. :) :) The identifier Ceiling_Locking doesn't seem to be anywhere in the index, either. **************************************************************** From: Christoph Grein Sent: Friday, November 14, 2008 1:34 AM Of course. In fact, I was looking for task dispatching policy identifiers, locking policy identifiers and restriction identifiers in the index, especially for No_Delay. It wasn't under N, and finally I found it under R, "Restrictions", which is the last place where to look. So I do think, these missing identifiers (FIFO_Within_Priorities, Ceiling_Locking etc) all have to appear in the index. **************************************************************** !topic Missing blanks before inserted text !reference Ada 2005 RM-6.5 [This is a comment on the draft consolidated standard - ED.] !from Christoph Grein 2008-12-16 !discussion Newly inserted text is missing a space. I found two such cases, but am sure there are a lot more occurrences like those. RM 6.5(5.2/3) ... The type of the subtype_indication shall be{ }covered by the result type of the function. (22/3) ... Upon completion of a return statement that applies to a callable construct{ }by the normal completion of a simple_return_statement... I found three more: RM 10.7(8/3,10/3,12/3) ... Status_Error is propagated if the file is not open.{ }Mode_Error is propagated if the mode of the file is not In_File. [He means A.10.7 - ED.] A simply typo: (28.f.1/3) ... However, it allows raising a[n] Constraint_Error in some cases... **************************************************************** !topic Grammatically wrong new text !reference Ada 2005 AARM 6.4.1(17.g/3) [This is a comment on the draft consolidated standard - ED.] !from Christoph Grein 2008-12-16 !discussion ... and requiring such cases to work would be a major change of the user model (in parameters {c}[w]ould no longer [could] be assumed constant). **************************************************************** !topic Wrong AI referenced !reference Ada 2005 AARM 4.1(17.h/3) [This is a comment on the draft consolidated standard - ED.] !from Christoph Grein 2008-12-18 !discussion This paragraph references AI05-0015-1, but the correct one is AI05-0003-1. **************************************************************** !reference Ada 2005 RM 4.5.6(11/3) [This is a comment on the draft consolidated standard - ED.] !topic The value of X**N with the value of the exponent N positive {is} the same as the value of... **************************************************************** From: Adam Beneschan Sent: Thursday, January 15, 2009 12:36 PM Last June, I posted a question to Ada-Comment, but I never received a response, nor did this end up in any AI's or AC's. So I think it may have fallen through the cracks. I'm reposting it in case that's what happened. [Followed by a reposting of the message filed June 11, 2008. - ED] **************************************************************** From: Randy Brukardt Sent: Thursday, January 15, 2009 1:03 PM Not true; it got filed into AI05-0005-1, and an appropriate AARM note added (A.11(4.a/3)). (No one I queried could imagine how it could mean anything else than both packages -- everything else in this section works that way -- so we didn't see the point of doing a full ARG resolution on it - especially as we had dozens of other comments [mostly from you! :-)] that actually need discussion.) See the working AARM at http://www.adaic.com/standards/1zaarm/html/AA-A-11.html. **************************************************************** From: Adam Beneschan Sent: Thursday, January 15, 2009 12:36 PM > Not true; it got filed into AI05-0005-1, and an appropriate AARM note > added (A.11(4.a/3)). (No one I queried could imagine how it could mean > anything else than both packages -- everything else in this section > works that way -- Actually, I didn't think there was anything else in the section to which that would even apply---i.e. there are no generic formal parameter *names* that are mentioned as names that are to be replaced. > so we didn't see the point of doing a full ARG resolution on it - > especially as we had dozens of other comments [mostly from you! :-)] > that actually need > discussion.) My fault. I searched the AI text files and didn't find it, but I must have either made a typo or searched for a string that got word-wrapped or something stupid like that. I'm not off to a good start this week... Time to go back to bed, I guess. (I can't even blame the extreme cold the way you could because it's been close to 90 here...) **************************************************************** !topic "/=" in the index !reference RM05 index !from Adam Beneschan 09-03-10 !discussion Index nitpick: The index has these two entries: / operator 4.4(1), 4.5.5(1) /= operator 4.4(1), 4.5.2(1) but I think the second one should also refer to 6.6(6) since this is a case where "/=" is implicitly defined by the language. **************************************************************** From: Christoph Grein Sent: Wednesday, April 1, 2009 4:12 AM [No joke!] Editorial comments (missing spaces between words, grammar mistakes etc...) [on Draft 7 - ED] 3.9.3(4/3) ... result, or if a type other than a non-abstract{ }null extension... 3.9.3(10/3) ... controlling result or a controlling access result{ }shall not... 6.5(24.a/3) ... The intention is that the exception is raised at {the} same point that it would have been raised without the permission; Question: 6.5(24.a/3) replaces build-in-place by built-in-place, but (24.d/3) keeps it. Is this intended? 6.6(6/3) An explicit declaration of "=" whose result type is Boolean implicitly declares an operator [of] "/=" that gives the complementary result. 6.6(6.a/3) There is an index entry "Number of the Beast". ??? You're reading too much in the Holy Bible - Ada was not a prophet, or was she? :-) 7.3.1(3/3) ... operators are implicitly declared at that place.{ }If there is no such place, ... 10.1.1(12.g.1/3) ... a discriminant_part even if the [the] type_declaration does have one. A.18.17(23/3) ... they guard against certain actions by the designated subprogram[.]{;} in particular, ... A.18.17(30.a/3) ... However, the order and number of calls on the formal equality function is unspecified, [so an implementation does not need to call ]so an implementation need not call ... 3.7(10.h.1/3) Any type may have an access discriminant, but access discriminants may have defaults only if they are an immutably {limited} type. Remark: was deleted and was meant to be replaced by , but was also inadvertantly deleted. BTW: Can a discriminant be a type? I presume the sentence should be: ... if they are {of} an immutably {limited} type **************************************************************** From: Randy Brukardt Sent: Friday, April 3, 2009 9:50 PM > Question: 6.5(24.a/3) replaces build-in-place by built-in-place, but > (24.d/3) keeps it. Is this intended? I don't think so; the next line uses "built-in-place". Probably incorrect muscle memory. ... > 6.6(6.a/3) There is an index entry "Number of the Beast". ??? > You're reading too much in the Holy Bible - Ada was not a > prophet, or was she? > :-) I'm just keeping up the tradition of joke index entries. But I'm probably not as funny as Bob Duff. Look up "unpolluted" in the AARM's index for an example. ... > A.18.17(23/3) ... they guard against certain actions by the > designated subprogram[.]{;} in particular, ... According to the AI, and according to the practice in the other clauses, this is supposed to start a sentence. That means that the problem is one of capitalization, not punctuation. > A.18.17(30.a/3) ... However, the order and number of calls on > the formal equality function is unspecified, [so an > implementation does not need to call ]so an implementation > need not call ... The AI was wrong on this one, having the dept. of redundancy department wording. **************************************************************** From: Bob Duff Sent: Sunday, June 7, 2009 8:08 AM > Unrelated aside: 13.14(1.j) is misleading, as all of these entities > have freezing and get frozen at particular points (for Convention and > address clauses at least); I think the point of the note is that we > don't use freezing per-se to handle most issues of premature access. Right, that was the intent. >...Probably ought to > be rewritten. **************************************************************** From: Christoph Grein Sent: Friday, June 19, 2009 12:03 AM There is a layout problem within the "task dispatching policy" on page 1117 (the PDF version). Non_Preemptive_FIFO_Within_Priorities (center column on top of page) is too long, so it merges with "termination handler" on the third column and the last 's' goes to the next line. (I see that other long entries like e.g. Ada.Numerics.Generic_Complex_- Elementary_Functions on the same page (withing Tan) are separated correctly. The separation algorithm somehow does not produce Non_Preemptive_FIFO_Within_- Priorities as it should.) **************************************************************** From: Christoph Grein Sent: Thursday, September 24, 2009 12:40 AM It appears to me that the sample code given in 6.3.1(21.d) is incorrect: with A; package B is package A_View renames A; function F_View(X : Integer := 9999) return Boolean renames F; -- wrong end B; should be "renames A.F" or "A_View.F" (F is not directly visible). **************************************************************** !topic Minor misspelling in AARM !reference 7.3(7.cc/2) !from Adam Beneschan 09-10-28 !discussion The second sentence of this paragraph reads, "A interface, like all types, is a descendant of itself, and thus this rule is triggered". That should be "An interface..." **************************************************************** !topic Wrong AI reference in AARM !reference AARM05 10.1.1(12.2/3, 12.3/3, 12.g.2/3) !from Adam Beneschan 09-11-12 !discussion In the AARM (www.adaic.org/standards/1zaarm/html/AA-10-1-1.html), the noted paragraphs have links to AI05-0134-1. This is wrong; they should refer to AI05-0129-1. [This refers to Draft 8 of the Ada 2012 manual.] **************************************************************** !topic Ada.Task_Termination and environment task !reference C.7.3, 10.2(11-12) !from Adam Beneschan 09-11-23 !discussion The semantics of Ada.Task_Termination seem to make it possible to call Set_Specific_Handler on the environment task, e.g. by using this Ada.Task_Termination.Set_Specific_Handler (Ada.Task_Identification.Current_Task, Prot_Object.Handler'access); in the main program. However, it appears to me that such a handler can never be successfully executed---or, at least, it is a bounded error to do so, since C.7.3(14/2) says that the handler is executed after other finalizations for the task are executed, and 10.2(11-12) implies that for the environment task, all library-level objects will be finalized, which includes all protected objects, which means that calling the termination handler is necessarily calling a protected subprogram of a protected object that has been finalized. Maybe this will work and maybe it won't (9.4(20.1/2)). This concerns me because I think the above call is something that someone is bound to try, since it seems like it would be a neat way to get something to happen when the environment task exits (perhaps due to an unhandled exception), but it's going to bite them. I believe that perhaps C.7.3 should clarify what happens when Set_Specific_Handler is called on the environment task (maybe in the Notes section), or perhaps the dynamic semantics should be changed to make Set_Specific_Handler raise a Program_Error if the task ID refers to the environment task. **************************************************************** From: Dan Eilers Sent: Saturday, January 9, 2010 5:44 PM in AARM 2012 6.3.1, paragraph 25.a.2/3 {AI05-0132-1} should be {AI05-0134-1} **************************************************************** From: Randy Brukardt Sent: Tuesday, April 6, 2010 4:28 PM In A.16(124.kk/2), "User_Id" in the first sentence should be "Group_Id". **************************************************************** !topic AARM error in 3.10.2 !reference AARM 3.10.2(22.n-22.r) !from Adam Beneschan 10-04-06 !discussion AARM 3.10.2(22.n through 22.q/2) says: 22.n: Most accessibility checking is done at compile time; the rules are stated in terms of "statically deeper than". The exceptions are: 22.q/2: Checks during function return and allocators, for nested type extensions and access discriminants. Then 22.r says Note that run-time checks are not required for access discriminants... which contradicts 22.q/2. Obviously this is a holdover from AARM95 and should be removed. **************************************************************** From: Randy Brukardt Sent: Tuesday, April 6, 2010 4:48 PM I think it would be more useful to add an exception for the cases mentioned in 22.q/2, since the model still is that run-time checks are not made for access discriminants in most cases. (General run-time checks for access discriminants would be very complex.) The checks that are made occur only on object creation (not use as one might expect) and only in cases where the object might live longer than the context of creation. So I suggest something like: Note that run-time checks are not required for access discriminants {(except during function returns and allocators)}, because ... **************************************************************** From: Tucker Taft Sent: Tuesday, May 11, 2010 4:36 PM The recently adjusted wording for this AARM note in 3.9.2 is grammatically incorrect: 20.b/3 Reason: {AI05-0005-1} The wording of the above rules [are] {is} intended to ensure ... **************************************************************** From: Randy Brukardt Sent: Wednesday, May 26, 2010 10:32 PM Storage_IO was added by Ada 95, but documentation of that fact is missing from the AARM. (And to think no one ever complained about that; the AARM has existed for 16 years...but Storage_IO was a late addition to Ada 95 - it first appeared in the July 1994 version.) **************************************************************** From: Christoph Grein Sent: Monday, June 14, 2010 5:44 AM 1.1.2(24.b/2) ... does not appear in the Ada 2005 {or Ada 2012} RM. [Editor's note: This particular item should only mention Ada 2012, since that is the document in hand.] **************************************************************** From: Christoph Grein Sent: Thursday, June 17, 2010 7:36 AM 4.1.4(6.h/2) ... The same would be true if (2) [was] {had} been a procedure; This is already in Ada 2005. **************************************************************** From: Adam Beneschan Sent: Thursday, July 1, 2010 7:50 PM Re: Typo in AARM 9.6.1(84.a/2) The last sentence of this says For example, "2005-08-31 24:0:0" should raise Constraint_Error (the hour is out or range). I think that was intended to be "2005-08-31 24:00:00"; otherwise it would raise Constraint_Error for an entirely different reason---the string isn't formatted as described for Image. **************************************************************** From: Christoph Grein Sent: Friday, July 30, 2010 2:16 AM Browsing thru AARM 2012 Draft 9, I've been wondering about the new operation Assign introduced in Lists, Maps, Sets what's the difference between Assign (A, B) and A := B. Finally I found in AI05-0001 the reason: "The Assign and Copy subprograms are needed for the bounded forms in order that containers with different capacities can be assigned or copied. The built-in assignment would raise Constraint_Error if the capacities were different. In order to keep the unbounded and bounded forms as similar as possible (to allow almost painless switching between forms), these subprograms were added to all of the existing containers." Shouldn't there be a little note in the RM at the end of each chapter or at least an annotation in the AARM about this? I guess more people will be wondering about the difference (where there is none). **************************************************************** From: Christoph Grein Sent: Thursday, February 3, 2011 7:24 AM 4.5.7(5.l/3) An if_expression and a{n} if_statement are very similar syntactically... 3.5.9(28.b) ... with a fixed point type whose small equals its delta equals a power of 10... This reads awkward. No proposal how to improve it. **************************************************************** The discussion in AC-00215 shows that an AARM note ought to be added to 4.3.1 in order to discuss where the positional order of components is formally defined for derived types and extensions. **************************************************************** The question of AC-00216 shows that the list of checks in 11.5 does not include Annex checks. There ought to be an AARM note that explains this. **************************************************************** From: Christoph Grein Sent: Tuesday, February 22, 2011 2:41 AM 10.1.4(7.a) ... their legality at that time. A{n} implementation model in which the environment consists... **************************************************************** From: Christoph Grein Sent: Friday, April 1, 2011 2:28 AM !topic Extended membership test !reference Ada 2005 AARM4.5.2(32.a/3), AI05-0158-1 !from Christoph Grein 2011-04-01 !discussion This is the formulation in AARM (draft 11): X not in A | B | C is intended to be exactly equivalent to not X in A | B This is the formulation in the AI: X not in A | B | C is intended to be exactly equivalent to not (X in A | B | C) Aren't the parens necessary because (not X) in A | B | C is also a valid interpretation, at least for Boolean and modular types? How would the expression without parens be resolved if both interpretations are legal? I see that this is also possible in the traditional form: not X in A .. B which will be evaluated as (not X) in A .. B if not X is a valid interpretation. **************************************************************** From: Randy Brukardt Sent: Friday, April 1, 2011 2:37 PM > Aren't the parens necessary ... Looks like sloppy work by the editor (that would be me), nothing more. I'll get it fixed. **************************************************************** From: Gary Dismukes Sent: Sunday, April 17, 2011 12:23 AM [Part of much larger message, see AI05-0264-1 for rest - Editor.] One AARM typo I noticed: ------------------------ AARM E.2.2(20.c/2) Typo: "(otherwise there would be a signficant..." "signficant" => "significant" **************************************************************** From: Christoph Grein Sent: Wednesday, July 6, 2011 7:43 AM 3.10.2(22.ii) The above illegal statements are illegal because the accessibility level{s} of X and Y are statically deeper... If you doubt the plural in this case, note that you use plural form in the last sentence of this para ;-) 3.10.2(22.hh) procedure P (X: {in out} T) is -- because... .. Ptr1: A1 := X'Access; -- OK (if X is a variable) **************************************************************** From: Christoph Grein Sent: Thursday, July 14, 2011 7:55 AM 13.11(43.b/3) ...A collection is an amorphous collection of objects ( mainly used to describe finalization of access types);... There is a space after the opening parenthesis "( mainly". "An X is a so-and-so X" sounds weird. I guess the first term "collection" means the Ada 83 technical term, the second the general English term. This has been like this since Ada 95, but I find it odd. **************************************************************** From: Randy Brukardt Sent: Monday, July 18, 2011 10:45 PM ...and not very helpful. Especially as the technical term has been reintroduced in Ada 2012. I changed the second "collection" to "grouping". Not quite as "pretty", but more likely to be helpful. **************************************************************** From: Dan Eilers Sent: Wednesday, August 17, 2011 2:06 PM [Editor's note: Just the AARM note errors are listed here.] ... These still remain: anomolies in AA-13.TXT: [Editor's note: 13.1(29.o/2)] namable in AA-03.TXT (twice), AA-05.TXT, AA-12.TXT (twice) [Editor's note: 3.2.2(8.a), 3.6(16.a), 5.4(18.d), 12.7(10.b) {twice}] oddies in AA-12.TXT [Editor's note: 12.5.1(5.b/2)] primarys in AA-04.TXT [Editor's note: 4.4(11.c); this can't be fixed as "primary" here is a syntax term.] **************************************************************** From: Dan Eilers Sent: Wednesday, August 17, 2011 2:41 PM [Editor's note: Just the AARM note errors are listed here. These are not marked as belonging to AI05-0005-1 since they already belong to other Ada 2005 AIs.] These typos are new in Draft 13: addressibility in AA-09.TXT (twice), AA-C.TXT [Editor's note: 9.10(15.d/3) (twice), C.6(24.e/3)] anonynous in AA-06.TXT [Editor's note: 6.3.1(25.i/3)] Asychronous in AA-J.TXT [Editor's note: J.15.13(4.a/3)] canoncial in AA-13.TXT [Editor's note: 13.11.4(21.b/3)] consistute in AA-07.TXT [Editor's note: 7.6.1(13.g/3)] decendant in AA-06.TXT [Editor's note: 6.5(8.e/3)] determing in AA-07.TXT [Editor's note: 7.6.1(13.g/3)] discrimiants in AA-06.TXT [Editor's note: 6.5(28.n/3)] exceution in AA-03.TXT [Editor's note: 3.10.2(7.d/3)] experessions in AA-06.TXT [Editor's note: 6.1.1(2.a/3)] inheritancee in AA-13.TXT [Editor's note: 13.13.2(25.a/3)] inmutably in AA-03.TXT [Editor's note: A.19(10.a/3)] Kingdon in AA-A.TXT [Editor's note: 3.7(10.b/3)] mades in AA-04.TXT [Editor's note: 4.4(7.b/3)] mutuable in AA-06.TXT [Editor's note: 6.5(28.n/3)] noticable in AA-07.TXT [Editor's note: 7.6(27.p/3)] overridding in AA-04.TXT [Editor's note: 4.5.2(39.k/3)] particalar in AA-A.TXT (twice) [Editor's note: A.18.2(230.a/3), A.18.3(144.a/3)] progentitor in AA-06.TXT (twice) [Editor's note: 6.1.1(23.a/3), 6.1.1(30.a/3)] substitition in AA-03.TXT [Editor's note: 3.4(21.b/3)] supercede in AA-13.TXT [Editor's note: 13.3(65.a/3)] syntactally in AA-04.TXT [Editor's note: 4.3(3.b/3)] "is is" in AA-A.TXT (6 times) [Editor's note: A.18.2(264.c/3), A.18.3(164.c/3), etc.] "of of" in AA-06.TXT [Editor's note: 6.5(21.e/3)] "that that" in AA-06.TXT [Editor's note: 6.1.1(16.d/3)] **************************************************************** From: Dan Eilers Sent: Thursday, August 18, 2011 11:33 AM Here are the unbalanced parens. 3.4(26.a/2) missing ")" "(see 3.9.4" 3.4(38.m/2) missing ")" "(this was never normatively specified in Ada 95." 3.5(27.c/2) missing ")" "(which is a bounded error anyway" 3.6.2(11/3) missing ")" "(Fortran is specified for a multidimensional array type" 3.7(37.k/2) missing ")" "(and eliminates confusion with derived types" 3.9.4(6.b/2) missing ")" "(see 3.2" 6.4.1(18.c/3) missing ")" "(which is similar to the behavior for constraints." 6.5(28.n/3) missing ")" "(returning an object with mutuable discriminants" 7.6(9.a) missing ")" "(rather than just "controlled type"" 9.4(11.g/2) "}" instead of ")" "(see 9.5.1}" 10.1.2(6.b/2) extra ")" "for visibility purposes.))" 13.1(8.c/3) extra ")" "(see J.15.5))" A.18.10(146/3) ";" instead of ")" "function Ancestor_Find (Position : Cursor; Item : Element_Type; return Cursor;" [Editor's note: These were just corrected as they are clearly typos that do not change the meaning of the text.] **************************************************************** From: Tullio Vardanega Sent: Sunday, September 12, 2011 11:44 AM 9.4 20.e: The environment task is queued on PO.EE whereas the language is case-insensitive, writing PO.EE instead of PO.Ee needlessy strains the reader D.2.2 21.b/2: it allows specifying should be "it allows the specification of" **************************************************************** From: Tucker Taft Sent: Monday, September 12, 2011 10:33 AM 13.2 5.b/3: Ramification: The only high level semantic effect of specifying the Pack aspect is {potential loss of} independent addressability (see 9.10, “Shared Variables”).[ ] ] **************************************************************** From: Brad Moore Sent: Saturday, September 17, 2011 1:14 AM AARM Specific comments [Editor's note: Only those affecting text from previous versions of the Standard are included here.] A.5.3 (62.a) "All of the primitive function attributes except Rounding and Machine correspond to subprograms in the Generic_Primitive_Functions generic package proposed as a separate ISO standard (ISO/IEC DIS 11729) for Ada 83." Is this still true? Presumably if it hasn't happend by now, it aint gonna happen. A.10.9 (35.a) What about Wide_Wide values? A.10.10 (11.a) What about Wide_Wide characters? A.10.10 (14.a) What about Wide_Wide characters? A.16 (106.a/2) "*Ramification: *The only way that a call to End_Search could be unsuccessful {would be} if Device_Error (see A.13 ) is raised because of an underlying failure (or bug). " E.2.2 (17.a/2) "*Reason: *All three of these restrictions are because " The list above has 6 bullets of restrictions, the last bullet (17/2) has 5 parts, so what do they mean when they say "all three" **************************************************************** From: Randy Brukardt Sent: Wednesday, September 21, 2011 9:14 PM > A.5.3 (62.a) "All of the primitive function attributes except > Rounding and Machine correspond to subprograms in the > Generic_Primitive_Functions generic package proposed as a > separate ISO standard (ISO/IEC DIS 11729) for Ada 83." > Is this still true? Presumably if it hasn't happend by now, > it aint gonna happen. I think we killed all of those Ada 83 standards in favor of the Ada 95 definitions. But if you read this as discussing ancient history (and anything involving Ada 83 is ancient history), it still seems valid. It probably would be slightly better if it said "...generic package {that was} proposed as ...", so I made that change. > A.10.9 (35.a) What about Wide_Wide values? The permission is question is wording naming all three attributes, so I rewrote this note to match. > E.2.2 (17.a/2) "*Reason: *All three of these restrictions are because " > > The list above has 6 bullets of restrictions, the last bullet > (17/2) has 5 parts, so what do they mean when they say "all three" The number comes from the Ada 95 notes, but even then it doesn't make sense (there are four bullets in Ada 95). I just dropped the number. **************************************************************** From: Randy Brukardt Sent: Thursday, October 13, 2011 11:15 PM A.18.5(51.b/2) refers to "Count", but there is no such parameter; the parameter to Reserve_Capacity is called "Capacity". **************************************************************** From: Dan Eilers Sent: Monday, October 31, 2011 4:52 PM intepretation AA-04.TXT: follow this intepretation. [Editor's note: 4.6(71.r/2).] sychronized AA-12.TXT: disallowing extending a sychronized non-interface type will be [Editor's note: 12.5.1(5.e/2).] useable --an allowable spelling but everywhere else says usable AA-03.TXT: useable characters. [Editor's note: 3.5.2(9.i/2).] **************************************************************** From: Steve Baird Sent: Friday, November 4, 2011 6:55 PM The AARM says this about 10.2.1(18/3) (pure call permissions): A declared-pure library_item has no variable state. Hence, a call on one of its (nonnested) subprograms cannot normally “normally” have side effects. The only possible side effects from such a call would be through machine code insertions, imported subprograms, unchecked conversion to an access type declared within the subprogram, and similar features. The compiler may omit a call to such a subprogram even if such side effects exist, so the writer of such a subprogram has to keep this in mind. Contrary to what this commentary suggests, it seems that a (loosely speaking) "pure" function can have side-effects without going outside the fully portable subset of Ada by using indirect calls to gain access to variable state. package Pure_Pkg is pragma Pure; function Foo (X : Some_Tagged_Type) return Integer; end; package body Pure_Pkg is function Foo (X : Some_Tagged_Type) return Integer is begin return Some_Dispatching_Function (Some_Tagged_Type'Class (X)); -- dispatches to code that has side effects end Foo; end Pure_Pkg; There is a similar situation with access-to-subprogram calls. I could certainly imagine a user being surprised if a compiler (as part of code generation) transforms while Pure_Pkg.Foo (X) /= 0 loop ... end loop; into Temp := Pure_Pkg.Foo (X); if Temp /= 0 then -- infinite loop if we get here loop ... end loop; end if; It is not clear that any language changes are needed here, but I think that the AARM paragraph is significantly misleading and that something like the following would be an improvement: A declared-pure library_item has no variable state. Hence, a call on one of its (nonnested) subprograms cannot normally “normally” have side effects. Side effects are still possible via dispatching calls and via indirect calls through access-to-subprogram values. Other mechanisms that might be used to modify variable state include machine code insertions, imported subprograms, and unchecked conversion to an access type declared within the subprogram; this list is not exhaustive. Thus, the permissions described in this section may apply to a subprogram whose execution has side-effects. The writer of such a subprogram has to keep this in mind. If it is decided that language changes are needed here because the current treatment of the example given above is unacceptable, then we have a lot of discussion ahead of us. I'm suggesting that we should at least accurately describe the current situation even if we aren't going to fix it right now. **************************************************************** From: Bob Duff Sent: Monday, November 14, 2011 4:30 PM I hope you can handle this as a minor editorial correction to AARM-7.6(17.k/3): 17.k/3 {AI05-0067-1} For function calls, we only require building in place for immutable types. ... ^^^^^^^^^ "immutable" should be "immutably limited". "immutable" means various things, including "discriminants can't change", which is not what was meant here. **************************************************************** From: Christoph Grein Sent: Wednesday, November 16, 2011 1:50 AM 2.1(6.a/2) ... as future characters can [be] already be used in Ada character and string literals. **************************************************************** From: John Barnes Sent: Thursday, December 22, 2011 8:47 AM [A small part of a larger review.] > A.4.3(109.d/3) It says "newly added" I would delete > "newly". It might seem odd in a couple of years time. [Editor's note: There are quite a few of these, and several in Ada 2005 text as well: 3.9(33.d/2), 11.4.1(19.bb/2), A.4.1(6.a/2), A.4.3(109.a/2), A.4.4(106.f/2), A.4.5(88.c/2), A.10.7(26.a/2), B.3(84.a/2), D.8(51.a/2). Ada 2012 occurrrences are just changed, Ada 2005 notes are marked and listed here.] **************************************************************** From: Brad Moore Sent: Wednesday, December 28, 2011 10:46 AM A.18.18 (49.a/3) "*Implementation Note: *The “tamper with the element” check is intended to prevent the Element parameter of Process from being [modified] {replaced} or deleted outside of Process." The definition of tampering only covers deletion (or complete replacement) of the Element. Modifying the element is not defined to be associated with tampering with the element. [Editor's note: There is a similar problem in A.18.2(137.a/2).] **************************************************************** From: Jean-Pierre Rosen Sent: Monday, January 2, 2012 8:20 AM [Just the relevant parts of a larger review. - Editor] 9.7.2(7.b/2) (Another old typo) A procedure can be used as the {target} in a timed or conditional entry call **************************************************************** From: Bob Duff Sent: Friday, January 13, 2012 7:55 PM [Just the relevant parts of a larger review. - Editor] > 3.3 Objects and Named Numbers > 23.b/3 There are other cases that could have been included in this > definition (view conversions, the current instance of a type, > implementation-defined attributes, objects of a formal > discriminated private type), but these are not relevant to the > places this term is used, so they were not included. If this term > is used in additional places, the definition should be checked to > see if any of these additional cases are relevant and appropriate > wording added if necessary. I suggest you remove "implementation-defined attributes". If it's impl-def, then the implementation gets to decide whether it is "known to be constrained", or any other property. > 3.7.2 Operations of Discriminated Types > 3.c/3 Discussion: {AI05-0214-1} If the type of A is a type derived from > an untagged partial view of a tagged type such that it is not a > tagged type, then A is not considered a tagged object, and > A'Constrained can return either True or False. I find that confusing -- it sounds like the implementation is allowed to roll dice, and return whatever it likes. I think adding, ", depending on the nature of the type", or ", depending on whether defaults exist" at the end would help. [Editor's note: "depending on the nature of the object" was used, because the object determines the value; the type only does if it is tagged.] > 3.9.2 Dispatching Operations of Tagged Types > 20.a.1/3 Ramification: {AI05-0126-1} "Corresponding dispatching > operation" refers to the inheritance relationship between subprograms. > Primitive operations are always inherited for a type T, but they > may not be declared if the primitive operation is never visible "may not" --> "might not" > within the immediate scope of the type T. If no corresponding > operation is declared, the last bullet is used and the > corresponding operation of the parent type is executed (an > explicit body that happens to have the same name and profile is > not called in that case). [Editor's note: this also occurs in 3.9(12.a/2) and 3.9.2(20.a.2/3).] > 3.10.2 Operations of Access Types > 15.a/3 Discussion: {AI05-0014-1} This rule applies even when no > dereference exists, for example when an access value is passed as > an access parameter. This rule ensures that implementations are > not required to include dynamic accessibility values with access > values. That seems wrong. Dynamic accessibility values are needed for access parameters and standalone variables, I think. ["all" is missing before "access values" - Editor.] **************************************************************** From: Tucker Taft Sent: Sunday, January 15, 2012 1:22 PM [Just the relevant parts of a larger review. - Editor] A.18.2(97.b/3) To be honest: This function [may] {might} not detect cursors that designate deleted elements; such cursors are invalid (see below) and the result of calling Has_Element with an invalid cursor is unspecified (but not erroneous). **************************************************************** From: Randy Brukardt Sent: Friday, January 27, 2012 11:55 PM This particular note is from Ada 2005; it was moved along with the subprogram (else it would not appear new). Just to review (I know Tucker knows this): "may not" shall not be used in ISO standards. It's not strictly banned from AARM notes, but it probably shouldn't be used anywhere, just to follow good habits. (ISO wants "need not" So I started a scrub of the standard to eliminate any lingering "may nots". But I found too many uses to bother with, especially after I found uses in normative text: A.5.1(18), G.1.1(38), and a note A.5.2(50). There also are a couple of places where the form "may or may not" is used (see G.2(1)); that's hard to replace. 11.6(5.d-f) has a bunch of "may not"s that really should be "must not"s, but that hardly helps (since we're not supposed to use "must", either, and neither "shall" or "can" have the right meaning, IMHO.) Even so, I changed "may not" to "might not" except as noted in the following: 1.1.2(39.n/2), 1.1.2(39.q/2), 1.1.2(39.t/2), 1.1.2(39.aa/3), 1.1.2(39.dd/3), 1.1.2(39.gg/3), 4.1.3(7.a/1) ("cannot"), 7.6.1(11.m/3) ("need not"), A.5.2(61.b/2), A.12.1(36.a/2), A.18.2(97.b/3), A.18.3(69.c/3), A.18.4(19.c/3), A.18.7(18.c/3), A.18.10(92.a/3), D.2.1(17.a/2), D.2.2(6.a/2), D.2.2(21.a/2), H.4(1.a), H.4(27.a). **************************************************************** Editor's note (January 27, 2012): All of the items above this marker have been included in the working version of the AARM. ****************************************************************