!standard 12.03 (11) 00-08-31 AI95-00114/00 !class confirmation 96-04-04 !status work item 96-04-10 !status received 96-04-04 !priority Low !difficulty Hard !subject Editorial Comments on AARM !summary This AI serves as a holder for editorial comments on AARM-only annotations. 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 !section 12.3(11) !subject but the{y} can be in instances. !reference AARM95-12.3(11.x) !from Keith Thompson 95-11-10 !reference 95-5384.a Keith Thompson 95-11-11>> !discussion **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 This issue was fixed in AARM 6.0 (of course, no one except Bob has that version :-). **************************************************************** !section 12.3(11) !subject It doesn't matter that [an] one could imagine ... !reference AARM-12.3(11.dd) !from Keith Thompson 95-11-17 !reference 95-5391.a Keith Thompson 95-11-17>> **************************************************************** !section 13.3(12) !subject Address clauses for components !reference AARM95-13.3(12) !from Keith Thompson 96-02-22 !reference 96-5429.a Keith Thompson 96-2-22>> !discussion The referenced paragraph in the AARM says: 12 {specifiable [of Address for stand-alone objects and for program units]} {Address clause} Address may be specified for [stand-alone] objects and for program units via an attribute_ definition_clause. The use of square brackets around the phrase "stand-alone" implies that it is redundant and can be proven from other rules. How does the restriction to stand-alone objects follow from other rules? In particular, why is this illegal (adapted from a posting to comp.lang.ada by Bob Gilbert)? protected Discretes is procedure Write(Settings : in Setting_List); private HW_Control : Discrete_HW_Control; for HW_Control use at Some_Legal_Address; end Discretes; I'm not suggesting that it should be, just asking how it can be proven from other rules. **************************************************************** !section 13.3(12) !subject Address clauses for components !reference AARM95-13.3(12) !reference 96-5429.a Keith Thompson 96-2-22 !from Bob Duff !reference 96-5456.a Robert A Duff 96-4-8>> !discussion > The referenced paragraph in the AARM says: > > 12 {specifiable [of Address for stand-alone objects and for > program units]} {Address clause} Address may be specified for > [stand-alone] objects and for program units via an attribute_ > definition_clause. > > The use of square brackets around the phrase "stand-alone" implies that it > is redundant and can be proven from other rules. How does the restriction > to stand-alone objects follow from other rules? Good question. Apparently, we thought that it was implied by 13.1(6.a): 6.a Ramification: The ``statically denote'' part implies that it is impossible to specify the representation of an object that is not a stand-alone object, except in the case of a representation item like pragma Atomic that is allowed inside a component_list (in which case the representation item specifies the representation of components of all objects of the type). It also prevents the problem of renamings of things like ``P.all'' (where P is an access-to-subprogram value) or ``E(I)'' (where E is an entry family). But I must admit that I don't see how this follows from the RM. In any case, the square brackets are AARM-only material, so the ARG can safely believe them, even if they don't strictly follow from other rules. That is, this is a bug in the AARM's use of brackets, but not a bug in the RM itself. >... In particular, why is > this illegal (adapted from a posting to comp.lang.ada by Bob Gilbert)? > > protected Discretes is > procedure Write(Settings : in Setting_List); > private > HW_Control : Discrete_HW_Control; > for HW_Control use at Some_Legal_Address; > end Discretes; > > I'm not suggesting that it should be, just asking how it can be proven > from other rules. The above was intended to be illegal, and *is* illegal by 13.3(12), despite its use of square brackets in the AARM. Anwyay, I think this can be taken as an editorial comment on the AARM, rather than a comment on the RM itself. - Bob **************************************************************** !section 13.3(12) !subject Address clauses for components !reference AARM95-13.3(12) !reference 96-5429.a Keith Thompson 96-2-22 !reference 96-5456.a Bob Duff 96-03-08 !from Keith Thompson !reference 96-5458.a Keith Thompson 96-4-8>> !discussion Bob Duff wrote: > In any case, the square brackets are AARM-only material, so the ARG can > safely believe them, even if they don't strictly follow from other > rules. That is, this is a bug in the AARM's use of brackets, but not a > bug in the RM itself. [...] > Anwyay, I think this can be taken as an editorial comment on the AARM, > rather than a comment on the RM itself. I agree. I hadn't realized (though I probably should have) that the phrase "stand-alone" does appear in the RM, without the brackets. **************************************************************** !section 13.1(14) !subject Errors in example !reference RM95-13.1(14) !from Jorgen Bundgaard 96-03-07 !keywords !reference 96-5434.a Joergen Bundgaard 96-3-7>> !discussion The example 13.1(14.c-e) contains other violations of the legality rules than those marked with "-- Illegal!": types A1 and A2 should be general access types, and the accessibility levels of the Obj1(17) and Obj2(17) should not be statically deeper than that of access types A2 and A1, respectively. **************************************************************** !section 3.9.2(20) !subject Illegal use of names in 3.9.2 example !reference AARM95-3.9.2(20.e) !from Ivan B. Cvar 96-09-19 !keywords dispatching operations !reference 96-5703.a Ivan B. Cvar 96-9-19>> !discussion The example in the Annotated Ada95 Reference Manual 3.9.2(20.e) fails to compile because it references 2 type names that are not visible at the point of use. However, the meaning of the example is clear, despite the errors, but you may want to repair the example for future releases. with P1; with P2; procedure Main is X : T2; --<<< ERROR: Should be P2.T2 Y : T1'Class := X; --<<< ERROR: Should be P1.T1 begin P2.Op_A(Param => X); -- Nondispatching call. P1.Op_A(Arg => Y); -- Dispatching call. P2.Op_B(Arg => X); -- Nondispatching call. P1.Op_B(Arg => Y); -- Dispatching call. end Main; **************************************************************** !section 7.3(7) !subject Semantic Errors in AARM 7.3 Examples !reference AARM-7.3(7.f) !reference AARM-7.3(7.h) !reference AARM-7.3(7.m) !from Ivan B. Cvar 96-08-01 !reference 96-5629.a Ivan B. Cvar 96-8-1>> !discussion There are 3 unintended semantic errors in Annotated Ada 95 Reference Manual clause 7.3, paragraphs 7.f, 7.h, and 7.m. They are: In the example of 7.3(7.f), the closing designator at the end of the body of procedure Foo is wrong. It should be Foo, not A. In the example of 7.3(7.h), the named association in the discriminant constraint denotes a discriminant named A, whereas the correct name is D, as declared in paragraph 7.g. In the example of 7.3(7.m), the package Q should have the context clause "with P; use P" to make the name of type Parent visible, and for consistency with 7.3(7.n) since 7.3(7.n) contains a with clause that denotes Q. **************************************************************** !topic Change from Ada 83 omitted !reference AARM-95 13.7 (37.d-38.d) !from Wes Groleau 98 Oct 06 !keywords System Null_Address incompatibility <> !discussion In LRM-83, no equivalent of System.Null_Address is required. Many vendors added it as an extension, but not all used the same name. AARM mentions UI-0065 (which I am still trying to locate) but doesn't specifically say it is a change. (Karl Grebyn's Ada 83 Annotations do not mention any Ada-83 standardization issue for this, so I presume there wasn't one until the 9X effort.) **************************************************************** !topic Object freezing and aspect clauses !reference RM95 13.14(19), 13.1 !from Adam Beneschan 11-18-02 !discussion I believe there's an omission from RM95 13.1 on the subject of an aspect clause on an object after the object is frozen. It seems clear to me that this was intended to be illegal. 13.14(19) says: An operational or representation item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.1) where "entity" includes objects as well as types. ACATS test bde0008 confirms that this is supposed to be illegal: type Enum is (Red, White, Yellow); ObjA : Enum; ObjB : Enum := ObjA; -- The nonstatic expression ObjA in the initialization expression of ObjB -- above freezes ObjA. The representation clause is therefore illegal. -- RM 13.14(4,8,19);6.0 for ObjA'Size use System.Storage_Unit; -- ERROR: -- Representation clause of a frozen object. The reason I think there's an omission is that the Legality Rules in 13.14(16-19) are all supposed to be repeats of rules that are stated elsewhere in the RM, and they all refer to other sections. The above rule refers to 13.1. However, there appears to be no language in 13.1 that makes it illegal for an aspect clause on an *object* to appear after the object is frozen. 13.1(9) and 13.1(9.1) make it illegal for types and subtypes, but there's no similar language in 13.1 that pertains to objects. This appears to me to be a simple typo, but it should be fixed. **************************************************************** From: Randy Brukardt Sent: Friday, November 22, 2002 11:16 PM The above comment has raised during the Corrigendum process, and was handled at that time. Note that the comment is only on the AARM, as there is no such thing as the RM rule "that is intended to be a repeat". If it's a normative rule (and this one is), it applies. We discussed this during the Corrigendum discussions. See the !appendix of AI-137 (toward the bottom). But the whole question is a bit silly. I don't see anything in 13.14(16-19) that indicates that it is some sort of repeat. Certainly, it is normative text in the standard. It's true that the Ada 95 AARM has the text in square brackets, but the AARM isn't normative in any way. There were several such AARM errors discovered before or during the Corrigendum work. The updated AARM that includes the Corrigendum changes does not include square brackets around 13.14(19) for this very reason: it is not redundant. (There are a couple of other, similar cases in the updated AARM.) In any case, this appears to be a comment on the AARM, not on the standard -- and the AARM change has already been made. So there is nothing that needs to be done here. **************************************************************** From: Randy Brukardt (Editor) Date: August 30, 2000 I've made the corrections needed to implement the presentation issues above in the updated AARM, or explained why the suggested correction was not (and will not) be made. Newer items below this item (if any) have *not* been handled. (They should be on the updated AARM). **************************************************************** From: Dan Eilers [dan@IRVINE.COM] Sent: Wednesday, October 18, 2000 8:29 PM !topic AI-00077 is undocumented extension to Ada83 !reference RM95-10.01.04 !from Dan Eilers !keywords extension !discussion The AARM should mention that AI-00077 is an extension to Ada83. [Editor's note: AI-00077 is a confirmation.] **************************************************************** From: Dan Eilers [dan@IRVINE.COM] Sent: Wednesday, October 18, 2000 8:33 PM !topic AI-00163 is undocumented incompatibility with Ada83 !reference RM95-4.5.5(18-20) !from Dan Eilers !keywords incompatibility !discussion The AARM should mention that AI-00163 is an incompatibility with Ada83. [Editor's note: AI-00163 is a confirmation.] **************************************************************** From: Dan Eilers [dan@IRVINE.COM] Sent: Wednesday, October 18, 2000 8:53 PM !topic undocumented inconsistency regarding 'size !from Dan Eilers !keywords inconsistency !discussion The AARM should mention that 'size is inconsistent with Ada83, as noted by Robert Dewar in his email attached to AI95-00163, as well as recent ARG email: > ... (we have found the incompatibilities in handling of Size to be FAR > more worrisome, since in general they cause different results with no > complaint at compile time). ... > If one user bumping into one incompatibility using one vendors compiler IS > enough justification for changing the language, I have a number of messages > to transmit to this list, starting with a complaint about what to me is the > gratuitous change in the handling of static expressions that makes LOTS of > Ada 83 programs illegal. ---- > ... The pragmatic > issues are that Ada 95 pinned down some things left undefined in Ada 83, > and did it in a manner which, while formally allowed by the 83 RM did > not correspond to the way most compilers did things (e.g. mandating > Natural'Size = Integer'Size - 1, which was clearly allowed by the > Ada 83 RM, but all Ada 83 compilers I worked with had Natural'Size = > Integer'Size [I have heard that the Intermetrics compiler had the > Ada 95 treatment, but I am not familiar with that Ada 83 compiler]. **************************************************************** !topic Most operations that yield[s] a String !reference AARM95-A.4.3(2.a) !from Christoph Grein 02-01-07 !discussion This typo is not a RM bug, since it is only in the AARM. Nevertheless it should be corrected. **************************************************************** From: John Barnes Sent: Tuesday, November 23, 2004 11:02 AM In C.7.1 we say Task_ID rather than Task_Id. It seems to me to be better to use ID and to break the rule that only the first letter is in caps. We do it consistently with IO. However, I just noticed that AI-266 and maybe others use Task_Id. And in 11.4.1 we have Exception_Id and Null_Id. Would someone like to make a ruling on this? I assume that we could do a global edit on the whole RM. Hmmm. **************************************************************** From: Randy Brukardt Sent: Tuesday, November 23, 2004 5:34 PM My personal opinion is that Task_ID is wrong. "Id" is an abbreviation for "Identifier", not an acronym of some sort. "IO" is an acronym for Input-Output. However, the Standard is consistent in using Task_ID; only the defect reports use Task_Id. It would be easiest to be consistent with that. OTOH, it occurs only in 4 existing clauses (C.7.1, C.7.2, D.5, and D.11), so changing it wouldn't be impossible. **************************************************************** From: Pascal Leroy Sent: Wednesday, November 24, 2004 9:34 AM I agree with this. Only acronyms should be all caps. We should be using Task_Id everywhere. **************************************************************** From: Robert I. Eachus Sent: Wednesday, December 3, 2003 7:53 AM >Feel free to send such suggestions to me. I added some index entries for the >Consolidated RM, and I'll be happy to do so again. I just ran into one that is not marginal at all. 3.8(12) should appear somewhere under discriminants in the index, for example: discriminant use in a record definition 3.8(12) This is the paragraph that requires that a discriminant must appear alone in a record declaration: "A name that denotes a noninherited discriminant is allowed within the declaration of the type, but not within the discriminant_part. If the discriminant is used to define the constraint of a component, the bounds of an entry family, or the constraint of the parent subtype in a derived_type_definition then its name shall appear alone as a direct_name (not as part of a larger expression or expanded name). A discriminant shall not be used to define the constraint of a scalar component." Of course I could recommend that we remove the restriction instead. ;-) But I just don't see that as a big deal. **************************************************************** From: Pascal Leroy Sent: Friday, November 26, 2004 8:39 AM 1.1.2(23.c) should say "certification" rather than "validation", because we should be consistent with the terminology of 18009. **************************************************************** From: Randy Brukardt Sent: Monday, December 13, 2004 8:35 PM The AARM note 3.3(22.a) is completely wrong; there is a legality rule that all untagged view conversions are reversible. This presumably was leftover from an early version of Ada 9x. Delete this rule. **************************************************************** From: Dan Eilers Sent: Monday, December 17, 2004 8:05 PM Running spell check finds: (On the December 2004 draft AARM) and and AA-3-10.html [3.10(9.l) - ED] as as RM-3-9-3.html [3.9.3(1/2) - Error in draft - ED] architechture AA-13-13-1.html [13.13.1(9.a.1/1) - ED] behaviour Defect1.html convinient AA-11-3.html [11.3(7.b/2) - Error in draft - ED] declared declared AA-3-9-3.html [3.9.3(3/2) - Error in draft - ED] Identificiation Defect1.html Internation AA-0-1.html, RM-0-1.html [Intro(0.3) - Error in draft - ED] interprestation AA-11-5.html [11.5(31.j/2) - Error in draft - ED] is is AA-13-5-2.html, RM-8-5-1.html [8.5.1(5/2) - Error in draft; 13.5.2(4.a) - ED] langauge AA-D-14.html, AA-D-15.html, RM-D-14.html, RM-D-15.html [D.14(2/2), D.15(2/2) - Error in draft - ED] mechansisms AA-10-1-4.html [10.1.4(7.d.1/1) - ED] of of RM-10-1-1.html [10.1.1(19/2) - Error in draft - ED] overridding AA-10-2-1.html, AA-8-5-4.html, RM-10-2-1.html [10.2.1(11.4/2) - Error in draft; 8.5.4(7.b.1/2) - ED] preelaboratable AA-0-29.html, AA-10-2-1.html, AA-11-4-1.html, RM-0-29.html, RM-11-4-1.html [10.2.1(11.1/2) [index]; 11.4.1(2/2); 11.4.1(3/2); 11.4.1(19.aa/2) - Errors in draft - ED] rules rules AA-3-9-4.html [3.9.4(12/2) - Error in draft - ED] specifable AA-13-1.html [13.1(24.4/1) - ED] that that AA-3-9.html [3.9(4.b/2) - Error in draft - ED] the the AA-M.html, RM-M.html [3.5(37.a/2) - Error in draft - ED] visiblity AA-10-1-3.html [10.1.3(18.b) - ED] **************************************************************** From: Erhard Ploedereder Sent: Tuesday, January 18, 2005 12:37 PM on the occassion of the pleasure of reviewing Chap 11, I traced consistency of "True" vs "true", "False" vs. "false" for all references to the boolean value in the RM. Amazingly consistent in favor of the upper-case, with a few deviations that should be fixed: "false" -> "False" in 3.5.6(7) D.10 (6,7,9) "true" -> "True" in Language summary (28) 9.6.1 (72/2, 74/2) D.6 (7) D.10 (6,7,9) Notes: The AARM always uses lower-case. I did not bother to keep track. Occasionally, as in "the condition is true" in the RM, I let that stand as a semantic statement rather than a reference to the literal value (compared to "the condition evaluates to True") **************************************************************** From: Pascal Leroy Sent: Tuesday, January 25, 2005 4:37 AM 3.5.9(18.e) uses "affect" rather than "effect". **************************************************************** From: Pascal Leroy Sent: Tuesday, January 25, 2005 4:40 AM 3.7(1.b) says a type and all of its subtypes have unknown discriminants if it is declared that way. But that isn't true even in Ada 95; a partial view may have unknown discriminants while the full view does not. Rephrase this in terms of views. **************************************************************** From: Pascal Leroy Sent: Tuesday, January 25, 2005 4:43 AM 3.7(26.a) and 3.7(30.a) give a list of places where unknown discriminants are allowed; in both places incomplete types are missing. **************************************************************** From: Pascal Leroy Sent: Tuesday, January 25, 2005 4:46 AM 3.8(11.a) says "specifiable". it should be "specified". **************************************************************** From: Pascal Leroy Sent: Tuesday, January 25, 2005 5:10 AM In 4.1(17.c), change "...the name denotes [the] {a} value rather than..." for consistency with the first part of the sentence. **************************************************************** From: Randy Brukardt Date: Monday, March 21, 2005 10:10 PM 13.7.1(12.b) is babbling about how some language-defined subprograms use a Storage_Array. However, all of the routines referenced use a Stream_Element_Array! While the point is true, it doesn't apply to any language-defined subprograms, so it makes little sense to talk about it. This AARM note belongs in 13.13.1, suitably changed to refer to Stream_Element_Arrays. **************************************************************** From: Randy Brukardt Date: Sunday, April 3, 2005 10:20 PM 13.3(38.d) says "... an implementation might choose to make Component_Size be 0 for an array of Booleans...". That would indicate that no space is allocated for the components -- pretty weird. The rest of the paragraph makes it clear that the size of 1 was meant. **************************************************************** From: Randy Brukardt Date: Saturday, April 9, 2005 7:50 PM 13.9.1(8.a) and 13.9.1(8.c) talk about "static constraints all the way down". But there is no such rule in the Standard. Tucker Taft believes this is left over from an early draft of Ada 9X. These notes should be fixed. **************************************************************** From: Randy Brukardt Date: Sunday, April 3, 2005 11:20 PM 13.3(76.d) mentions that we don't use Storage_Array for portability. But this is talking about a streams, so it should say Stream_Element_Array. **************************************************************** From: Randy Brukardt (Editor) Date: April 11, 2005 I've made the corrections needed to implement the presentation issues above in the updated AARM (Amendment 1 version), or explained why the suggested correction was not (and will not) be made. Such changes are marked with a cross-reference to this AI. Newer items below this item (if any) have *not* been handled. (They should be on the updated AARM). ****************************************************************