!standard 10.01.05 (05) 99-08-31 AI95-00136/06 !class binding interpretation 96-05-07 !status Corrigendum 2000 99-05-27 !status WG9 approved 96-12-07 !status ARG approved 12-0-0 96-10-07 !status ARG approved (subj. ed. rev., letter ballot was 12-0-0) 96-10-03 !status ARG approved 9-0-0 (subject to letter ballot) 96-06-17 !status work item 96-05-08 !status received 96-05-07 !priority Medium !difficulty Easy !qualifier Error !subject Placement of Program Unit Pragmas in Generic Packages !summary A program unit pragma for a generic package must appear at the beginning of the package specification, and not in the generic formal part. For any program unit, such a pragma must not appear in the private part. !question Consider: generic pragma Pure; -- (a) Legal? (No.) type F is . . . package G is pragma Pure; -- (b) Legal? (Yes.) type T is . . . end G; 10.1.5(5) says the pragma shall appear: Immediately within the declaration of a program unit and before any nested declaration, in which case the argument, if any, shall be a direct_name that denotes the immediately enclosing program unit declaration. This seems to imply that the pragma Pure belongs at (a), and not at (b). Is this the intent? (No.) Consider also: package P is -- No declarations here. private pragma Pure; -- Legal? (No.) end P; !recommendation (See summary.) !wording Modify 10.1.5(5): Immediately within the [declaration] {visible part} of a program unit and before any nested declaration {(but not within a generic formal part)}, in which case the argument, if any, shall be a direct_name that denotes the immediately enclosing program unit declaration. !discussion It was not the intent to allow or require a program unit pragma for a generic package at the beginning of the generic formal part. Furthermore, such a placement would be strange and confusing. Thus, the wording of 10.1.5(5) is incorrect in this case. Likewise, it was not the intent to allow placement within a private part, just because there happen to be no declarations in the visible part. Allowing that would introduce a small but pointless implementation burden, and would be confusing, since Pure and so forth represent externally visible properties of program units. Note that for a generic unit, the term "visible part" officially includes the generic formal part. !corrigendum 10.01.05(5) @drepl @xbullet< Immediately within the declaration of a program unit and before any nested declaration, in which case the argument, if any, shall be a @fa that denotes the immediately enclosing program unit declaration.> @dby @xbullet< Immediately within the visible part of a program unit and before any nested declaration (but not within a generic formal part), in which case the argument, if any, shall be a @fa that denotes the immediately enclosing program unit declaration.> !ACATS test Test BA15002 was created to insure that program unit pragmas are not given in the formal part of a generic package or private part of a package. Test CA15003 was created to check that program unit pragmas can be given in a generic package. !appendix !section 10.1.5(05) !subject Placement of Program Unit Pragma !reference RM95-10.1.5(5) !from Ivan B. Cvar 96-04-25 !keywords pragma program-unit-pragma library-unit-pragma !reference 96-5518.a Ivan B. Cvar 96-4-25>> !discussion Here's a copy of a note we sent to Tucker Taft on this topic, followed by his response... -------------attachment starts here------------- Date: Thu, 25 Apr 1996 14:36:28 -0400 To: stt@dsd.camb.inmet.com Subject: pragma placement Cc: ibc, stg We have some questions about legality of pragma placement. Please correct our thinking. generic pragma pure ( x ); --(a) --Q1: is this legal per 10.1.5(5)? --Q2: is this placement required? --Q3: what if type F was omitted? type F is . . . package x is pragma pure ( x ); --(b) --Q4: is this illegal placement per 10.1.5(5)? --Q5: what if type F was omitted? type Y is . . . end; Re. pragma at (a): We couldn't find any LRM rule in 2.8, 10.1.5, or elsewhere, that prohibits placement (a), although our interpretation of 10.1.5(5) seems to demand it only when "type F" is present, but it merely allows (ie, not demands) it when "type F" is absent. Re. pragma at (b): Our interpretation of 10.1.5(5) is that placement (b) is illegal when "type F" is present, but both (a) and (b) are permissable (even at once) when "type F" is absent. Lastly, Q6: Does 10.1.5(5) "immediately within the declaration of a program unit" intentionally exclude any body other than a non-generic subprogram body? It seems to us that _no_ other body is a "declaration", except 6.3(5) allows that a "subprogram_body is a declaration" (and we also presume that this does _not_ apply to the body of a generic subprogram). Date: Thu, 25 Apr 1996 14:58:27 -0400 To: stg@ocsystems.com, stt@dsd.camb.inmet.com Subject: Re: pragma placement Cc: ibc@ocsystems.com > We have some questions about legality of pragma placement. Please correct our > thinking. > > generic > pragma pure ( x ); --(a) --Q1: is this legal per 10.1.5(5)? > --Q2: is this placement required? > --Q3: what if type F was omitted? > type F is . . . > package x is > pragma pure ( x ); --(b) --Q4: is this illegal placement per 10.1.5(5)? > --Q5: what if type F was omitted? > type Y is . . . > end; Our intent was always position(b), never position(a). I admit that on rereading 10.1.5(5), that is not immediately obvious. Some sort of "clarification" AI is probably appropriate. Feel free to send a note to ada-comment to the effect that you are presuming position (b) was meant. > ... > Lastly, Q6: > Does 10.1.5(5) "immediately within the declaration of a program unit" > intentionally exclude any body other than a non-generic subprogram body? Yes. Furthermore it only applies to spec-less subprogram bodies, because only these are *the* declaration of a program unit. > It seems to us that _no_ other body is a "declaration", except 6.3(5) allows > that a "subprogram_body is a declaration" (and we also presume that this does > _not_ apply to the body of a generic subprogram). A subprogram_body is *a* declaration, but it is only *the* declaration of a program unit if it has no separate spec. This is specified in the first sentence of 6.3(4), and reiterated in 6.3(5). When it has a separate spec, it is a "completion" and does not actually "declare" the subprogram. Subtle, eh? -Tuck -------------attachment ends here------------- ****************************************************************