Version 1.6 of ai05s/ai05-0077-1.txt

Unformatted version of ai05s/ai05-0077-1.txt version 1.6
Other versions for file ai05s/ai05-0077-1.txt
!standard 10.1.2(12/2)          08-04-18 AI05-0077-1/03
!standard 10.1.2(21/2)
!standard 10.1.2(22/2)
!class binding interpretation 07-12-07
!status WG9 Approved 08-06-20
!status ARG Approved 8-0-0 08-02-09
!status work item 07-12-07
!status received 07-12-05
!priority Medium
!difficulty Easy
!qualifier Error
!subject The scope of a declaration does not include any context clause
!summary
A limited_with_clause for a package P shall not appear in a context_clause that appears on a child unit that is within the scope of a nonlimited_with_clause that mentions P or a use_clause that names an entity declared in P.
!question
The declarative region of any entity includes the declarations of any child units (8.1(9)) and a child unit is a library unit (10.1.1(1)). A library unit is declared by a library_item ( 10.1.1(9)), and library_item doesn't include the context_clause (10.1.1(3)). Thus, a context_clause is not part of any declarative region. (AARM 10.1.6(6.c) says this explicitly).
However, both 10.1.2(21/2) and 10.1.2(22/2) say that a limited_with_clause shall not appear within the scope of an entity. Since the scope of an entity is defined in terms of its declarative region, it is impossible for a limited_with_clause (which must be in a context_clause) to ever be within the scope of anything. It's unlikely that was the intent of these two rules. What was meant?
!recommendation
(See Summary.)
!wording
In 10.1.2(12/2), replace "library item" with "library_item". Do the same in AARM notes 10.1.2(16.b/2) and 10.1.2(31.h/2).
Replace 10.1.2(21/2) with:
* within a context_clause for a library_item which is within the
scope of a nonlimited_with_clause that mentions the same library package; or
AARM Ramification: This applies to nonlimited_with_clauses found in the same context_clause, as well as nonlimited_with_clauses found on parent units.
Replace 10.1.2(22/2) with:
* within a context_clause for a library_item which is within the
scope of a use_clause that names an entity declared in the declarative region of the library package.
AARM Ramification: This applies to use_clauses found in the same context_clause, as well as use_clauses found in (or on) parent units.
!discussion
It is intentional that the declarative region of an entity does not include any context_clause. AARM 10.1.6(6.a-6.c) discuss the reasons for this. As such, changing the meaning of declarative region would be a very bad idea.
Instead, we focus on the library_item that is associated with the context_clause. If it is within the scope of an appropriate entity, then a limited_with_clause in the context_clause is illegal.
Note that we could have said "library_unit_declaration" rather than "library_item" in the wording, as limited_with_clauses are not allowed on bodies, renamings, or subunits. However, this seems more specific than necessary, is wordier than necessary, and could present a future maintenance hazard for the Standard.
During the work on this AI, we discovered that the term "library item" was used in this clause; but that only the syntactic term "library_item" is actually defined. We corrected the wording to fix that error.
!corrigendum 10.1.2(12/2)
Replace the paragraph:
A name denoting a library item that is visible only due to being mentioned in one or more with_clauses that include the reserved word private shall appear only within:
by:
A name denoting a library_item that is visible only due to being mentioned in one or more with_clauses that include the reserved word private shall appear only within:
!corrigendum 10.1.2(21/2)
Replace the paragraph:
by:
!corrigendum 10.1.2(22/2)
Replace the paragraph:
by:
!ACATS Test
This is tested by existing ACATS objectives which test the intent, not that actual rules.
!appendix

!topic Error in 10.1.2(22)
!reference RM05 10.1.2(19,22), 8.4(6)
!from Adam Beneschan 07-12-05
!discussion

I believe that the rule in 10.1.2(22) is worded incorrectly.

Starting with paragraph 19, this says:

   A limited_with_clause that names a library package shall not
   appear: ...

   in the same context_clause as, or within the scope of, a use_clause
   that names an entity declared within the declarative region of the
   library package.

8.4(6) says that the scopes of use_clauses do not include context
clauses.  Since a limited_with_clause appears only in a context
clause, this would mean that a limited_with_clause cannot appear in
the scope of any use_clause.  Therefore, the wording "within the scope
of" in 10.1.2(22) cannot be correct.

Perhaps the phrase between the commas should be changed to something
like "or in the context_clause of a compilation unit that is within
the scope of".  

(However, I think 10.1.2(21), which is similarly worded, is OK since
it seems that the scope of a with_clause does have to include context
clauses, and that the scope of a with_clause on P includes context
clauses on a child unit P.Q.)

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

From: Adam Beneschan
Sent: Wednesday, December 5, 2007 11:37 AM

Earlier, I wrote:
 
> I believe that the rule in 10.1.2(22) is worded incorrectly.
> 
> Starting with paragraph 19, this says:
> 
>    A limited_with_clause that names a library package shall not
>    appear: ...
> 
>    in the same context_clause as, or within the scope of, a use_clause
>    that names an entity declared within the declarative region of the
>    library package.
> 
> 8.4(6) says that the scopes of use_clauses do not include context
> clauses.  Since a limited_with_clause appears only in a context
> clause, this would mean that a limited_with_clause cannot appear in
> the scope of any use_clause.  Therefore, the wording "within the scope
> of" in 10.1.2(22) cannot be correct.
> 
> Perhaps the phrase between the commas should be changed to something
> like "or in the context_clause of a compilation unit that is within
> the scope of".  

It's occurred to me that a little care may be needed in fixing this.
Consider: 

   package Pak1 is
      package Nested is
         ...
      end Nested;
   end Pak1;

   with Pak1;
   package Pak2 is
      package Rename_Pak1 renames Pak1;
   end Pak2;

   with Pak2;
   package Pak3 is
      ...
      ...
   private
      use Pak2.Rename_Pak1.Nested;
   end Pak3;

   limited with Pak1;        -- legal??
   package Pak3.Child is
      ...
   private
      ...
   end Pak3.Child;

What, exactly, is the scope of the "use Pak2.Rename_Pak1" clause?
Obviously, the "limited with" itself is not in this scope.  The
entirety of Pak3.Child isn't in the scope, either, since the portion
of text before the word "private" isn't in the scope.  

But it seems that the "limited with" should still be illegal, since a
portion of Pak3.Child (i.e. the private part) is within the scope of
the "use" clause---and the same visibility problems that 10.1.2(22)
was intended to address would still exist within the private part if
the "limited with" were allowed.

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

From: Pascal Leroy
Sent: Wednesday, December 5, 2007  11:34 AM

> 8.4(6) says that the scopes of use_clauses do not include context 
> clauses.  Since a limited_with_clause appears only in a context
> clause, this would mean that a limited_with_clause cannot appear in
> the scope of any use_clause.  Therefore, the wording "within the scope
> of" in 10.1.2(22) cannot be correct.

I don't think so.

The case that we are interested in is not 8.4(6), it's 8.4(7).  It's the
case where the limited with appears on a child unit, but the parent unit
has, in some declarative part, a use_clause that names the same package. 

I don't see any wording in 8.4(7) saying that the context_clause is excluded
from the scope of such a use_clause.

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

From: Pascal Leroy
Sent: Wednesday, December 5, 2007 12:06 PM

> What, exactly, is the scope of the "use Pak2.Rename_Pak1" clause? 
> Obviously, the "limited with" itself is not in this scope.

You may be right, but there is nothing "obvious" here.  

8.4(7) has: "For a use_clause immediately within a declarative region, the
scope is the portion of the declarative region starting just after the
use_clause and extending to the end of the declarative region. However,
the scope of a use_clause in the private part of a library unit does not
include the visible part of any public descendant of that library unit."

The declarative region in question includes the declarations of any child
units (8.1(9)) and a child unit is a library unit (10.1.1(1)).  A
library unit is declared by a library_item ( 10.1.1(9)), and library_item
doesn't include the context_clause (10.1.1(3)).  So according to this line
of reasoning a context_clause is not part of any declarative region.

But note that this has nothing to do with the last sentence of 8.4(6),
which only applies to a use_clause appearing in a context_clause.  In fact,
this sentence would seem to be redundant.

One way to fix this would be to say that the context_clause of a unit is
actually part of its declarative region.  This is what I had been assumed all
along, before I looked at the details. 

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

From: Edmond Schonberg
Sent: Wednesday, December 5, 2007 12:58 PM

> I don't see any wording in 8.4(7) saying that the context_clause is  
> excluded from the scope of such a use_clause.


I agree, the wording in 10,1,2 (22) is correct.
(By the way, GNAT rejects the proposed example, as desired).

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

From: Tucker Taft
Sent: Wednesday, December 5, 2007  1:21 PM

Beware of 10.1.6(6.b-6.d).  This explicitly says
that a context clause is not in any declarative
region, and attempts to explain why.

I think Adam is right that we need a different
way of saying that a limited with clause is
not legal in certain context clauses due
to "enclosing" use clauses.  Using "scope"
doesn't work, at least not as scope is currently
defined.  10.1.6 is all about special visibility
rules in context clauses and friends, so this might
be a place to find and/or define a term that we need.

I suppose we could say in 10.1.2(22), "for the
purposes of this rule, a limited with clause
is 'within the scope of a use clause' if any
part of the compilation unit is within the scope
of the use clause" though that seems a bit
bogus.

In any case, I think we do have an inconsistency
here. particularly given what 10.1.6(6.c) says.

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

From: Tucker Taft
Sent: Wednesday, December 5, 2007  1:35 PM

I suppose using the "scope of a non-limited with clause" in
10.1.2(21) has the same problem.  Perhaps because
of the rules in 10.1.6, it is irrelevant whether
context clauses are considered to be within the scope
of "enclosing" with/use clauses.  We could define
which context clauses we want to be in the scope of
a with/use clause simply so we could use the terms
in 10.1.2(21,22).  Alternatively, we could use the
somewhat more circuitous wording about "a context
clause for a compilation unit any part of which
is in the scope of a use/non-limited-with clause."

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

From: Adam Beneschan
Sent: Wednesday, December 5, 2007  1:32 PM

> The case that we are interested in is not 8.4(6), it's 8.4(7).  It's the
> case where the limited with appears on a child unit, but the parent unit
> has, in some declarative part, a use_clause that names the same package.

Why does the use_clause have to be in a declarative part?  In my first
post on this, I didn't say anything about where the use_clause
appeared.  Is there any reason why the problem addressed by 10.1.2(22)
in this case:

   package Pak1 is
      package Nested is
         ...
      end Nested;
   end Pak1;

   with Pak1;
   package Pak2 is
      package Rename_Pak1 renames Pak1;
   end Pak2;

   with Pak2;
   use Pak2.Rename_Pak1.Nested;
   package Pak3 is
   end Pak3;

   limited with Pak1;        
   package Pak3.Child is
   end Pak3.Child;

is any different from the problem that would occur if the "use
Pak2.Rename_Pak1.Nested" were moved down one line?  I don't see it. 

Furthermore, I don't see any particular reason why the scope of a
use_clause appearing in a declarative part should include context
clauses while the scope of a use_clause appearing in a context_clause
should not.  

Furthermore, I don't think context clauses are included anyway,
because I don't think declarative regions include context clauses.
Looking at 8.1, it appears that a declarative region is comprised of
declarations or portions of declarations---but looking at 10.1.1(2-4),
a context_clause is separate from a declaration, not part of it.  That
could be why the phrase "The scope does not include context_clauses
themselves" appears in square brackets both in RM95 and RM05.  (Tucker
also pointed out that 10.1.6(6.c) in the AARM says this explicitly.)

By the way, this affects my earlier statement about whether 10.1.2(21)
is OK.  If I'm right that a declarative region never contains context
clauses, then 10.1.2(21) is wrong also.

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

From: Pascal Leroy
Sent: Wednesday, December 5, 2007  1:41 PM

> In any case, I think we do have an inconsistency
> here. particularly given what 10.1.6(6.c) says.

Agreed.

> I suppose we could say in 10.1.2(22), "for the
> purposes of this rule, a limited with clause
> is 'within the scope of a use clause' if any
> part of the compilation unit is within the scope
> of the use clause" though that seems a bit
> bogus.

Yuck.  I hate it when we have to say "for the purposes of...".

Instead of "within the scope of a use_clause" we could say "within a
context_clause for a library_unit_declaration which is within the
scope of a use_clause".  That would have the desired effect.  It would
also cover the situation where the use and the with are "within the
same context_clause".  So 10.1.1(22) would look like:

o  within a context_clause for a library_unit_declaration which is
within the scope of a use_clause that names an entity declared in the
declarative region of the library package.

****************************************************************
Questions? Ask the ACAA Technical Agent