Version 1.2 of ais/ai-00136.txt

Unformatted version of ais/ai-00136.txt version 1.2
Other versions for file ais/ai-00136.txt

!standard 10.01.05 (05)          99-06-25 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
!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:
5 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):
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)
Replace the paragraph:
by:
!ACATS test
A B-Test should be created to insure that program unit pragmas are not given in the formal part of a generic package or private part of a package. A C-Test should be 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-------------

****************************************************************

Questions? Ask the ACAA Technical Agent