!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. !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.) **************************************************************** 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). ****************************************************************