CVS difference for ai05s/ai05-0206-1.txt
--- ai05s/ai05-0206-1.txt 2010/02/23 07:31:06 1.2
+++ ai05s/ai05-0206-1.txt 2010/10/22 01:15:29 1.3
@@ -1,29 +1,37 @@
-!standard E.2.2(6) 10-02-15 AI05-0206-1/01
+!standard A(5/3) 10-10-21 AI05-0206-1/02
+!standard E.2(5)
+!standard E.2(9)
+!standard E.2(10)
+!standard E.2.2(6)
+!standard E.2.3(8)
!class binding interpretation 10-02-15
!status work item 10-02-15
!status received 10-01-15
!priority Low
!difficulty Medium
!qualifier Omission
-!subject Remote_Types packages should be able to depend on Preelaborated packages
+!subject Remote_Types and Remote_Call_Interface packages should be able to depend on Preelaborated packages
!summary
-A Remote_Types package can semantically depend on a Preelaborated package so
-long as that dependency is via private with clause.
+A Remote_Types package or a Remote_Call_Interface package can semantically
+depend on a preelaborated package if that dependency is via a private with
+clause.
!question
-The restrictions for Remote_Types packages are intended to allow the visible
-part of the package to meet various requirements. The bodies of Remote_Types
-packages have weaker requirements; they can declare non-remote access types, for
-instance. It is annoying that such types cannot be imported into a Remote_Types
-package.
+The restrictions for Remote_Types and Remote_Call_Interface packages are
+intended to allow the visible part of the package to meet various requirements.
+The bodies of Remote_Types and Remote_Call_Interface packages have weaker
+requirements; they can declare non-remote access types, for instance. It is
+annoying that such types cannot be imported into a Remote_Types package or a
+Remote_Call_Interface package.
For instance, the following is a useful organization, which is illegal in Ada
today:
package X is
+ pragma Preelaborate (X);
type T is null record;
type T_Access is access all T;
end X;
@@ -48,23 +56,71 @@
!wording
-** TBD **
+Delete paragraph A(5/3) [Added by AI05-0060-1].
-!discussion
+Modify E.2(5):
+
+The various categories of library units and the associated restrictions are
+described in this clause and its subclauses. The categories are related
+hierarchically in that the library units of one category can depend semantically
+only on library units of that category or an earlier one, except that the body
+of a remote types or remote call interface library unit is unrestricted {and the
+declaration of a remote types or remote call interface library unit may depend
+on preelaborated normal library units that are mentioned only by private with
+clauses}.
+
+Modify E.2(9):
+Remote Types
+ The declaration of the library unit can depend only on other remote types
+ library units, or one of the above{, or preelaborated normal library units
+ that are mentioned only by private with clauses}; the body of the library
+ unit is unrestricted;
+
+Modify E.2(10):
+
+Remote Call Interface
+ The declaration of the library unit can depend only on other remote call
+ interfaces, or one of the above{, or preelaborated normal library units that
+ are mentioned only by private with clauses}; the body of the library unit is
+ unrestricted;
+
+Modify E.2.2(6):
+it shall depend semantically only on declared pure, shared passive, or other
+remote types library units{, or preelaborated normal library units that are
+mentioned only by private with clauses};
+
+Modify E.2.3(8):
+The declaration of an RCI library unit shall be preelaborable (see 10.2.1), and
+shall depend semantically only upon declared pure, shared passive, remote types,
+or other remote call interface library units{, or preelaborated normal library
+units that are mentioned only by private with clauses}.
-The body of a Remote_Types unit can depend on preelaborated packages, but
-not "regular" packages (as a Remote_Types unit is considered preelaborated,
-so 10.2.1(11/1) applies). Extending such access to private parts seems
-reasonable, ans shouldn't be able to open up any new holes.
-
-Note that this change probably eliminates the need for A(4) (since all of the
-packages in question are already preelaborated); we should consider dropping
-that rule. As such, this is considered an update of AI05-0060-1, and is
-classified as a Binding Interpretation (as is AI05-0060-1).
+!discussion
---!corrigendum A.4.4(3)
+The body of a Remote_Types unit or a Remote_Call_Interface unit is unrestricted
+with regard to its semantic dependences. The specification of such a package
+however needs to be preelaborable.
+
+Allowing the private part of a Remote_Types package or a Remote_Call_Interface
+package to import a preelaborated package shouldn't be able to open up any new
+holes, and would not violate any of the existing restrictions on the visible
+part of the package.
+
+We considered whether to allow remote types and RCI library units to depend
+semantically on preelaborable library units in addition to preelaborated library
+units. This was ruled out because the implementation difficulty would be
+substantially higher since it would require the compiler to analyze whether the
+mentioned package is in fact preelaborable.
+
+Paragraph A(5/3) was deleted because it was originally intended to allow vendors
+that didn't implement Annex E, to "with" any packages needed to implement the
+private part of the standard library units, since being only able to "with" pure
+units is very restrictive. This AI relaxes this restriction considerably by
+allowing packages to privately "with" preelaborated packages. There is no longer
+enough justification to keep the paragraph in the RM.
+--!corrigendum A(5/3)
!ACATS test
@@ -724,5 +780,105 @@
Even ignoring (1), (2) means that new ideas have a very high bar at this point,
and (3) means this isn't within a country mile of that bar.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, October 16, 2010 5:45 PM
+
+ This package deals with allowing a Remote_Types package specification to
+ privately with preelaborable packages.
+
+First question. Should the subject title of the AI change the word
+"Preelaborated" to "preelaborable"? My interpretation of the RM is that only
+packages that have a pragma Pure, or pragma Preelaborate, are "preelaborated"
+10.2.1 (11/3).
+
+The example in the AI wants to be able to with the following package.
+
+package X is
+ type T is null record;
+ type T_Access is accerss all T;
+end X;
+
+This package does not seem to fall under the definition of "preelaborated".
+It does however, fall under the definition of "preelaborable" 10.2.1(5)
+
+I find this distinction between "preelaborable" and "preelaborated" is confusing
+in 10.2.1(11/3) when it talks about the limited view of a package.
+
+"In addition, the limited view of a library package is preelaborated. "
+this seems to conflict with the previous sentence.
+
+"The declaration and body of a preelaborated library unit, and all subunits that
+are elaborated as part of elaborating the library unit, All compilation units of
+a preelaborated library unit shall be preelaborable"
+
+If you have a limited with for a package that is not preelaborated, what does it
+mean for a limited view of a library package to say that the body and and all
+subunits elaborated as part of elaborating the library unit shall be
+preelaborable?
+
+Wouldn't it make more sense to say instead, "In addition, the limited view of a
+library package is *preelaborable*."?
+
+Next question. This AI is attempting to relax the restrictions on Remote_Types
+packages. Wouldn't it also make sense to relax the same restrictions on
+Remote_Call_Interface packages?
+
+I see no reason why we wouldn't want to also be able to privately with
+preelaborable packages into RCI package specifications.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, October 17, 2010 11:35 PM
+
+> First question. Should the subject title of the AI change the word
+> "Preelaborated" to "preelaborable"?
+> My interpretation of the RM is that only packages that have a pragma
+> Pure, or pragma Preelaborate, are "preelaborated"
+> 10.2.1 (11/3).
+
+No. Cateogorizations in Ada build upon one another. "Preelaborated" is a
+categorization, "preelaboratable" is a rarely calculated property of an entity.
+
+> The example in the AI wants to be able to with the following package.
+>
+> package X is
+> type T is null record;
+> type T_Access is accerss all T;
+> end X;
+>
+> This package does not seem to fall under the definition of "preelaborated".
+> It does however, fall under the definition of "preelaborable"
+> 10.2.1(5)
+
+It needs the pragma added if it is going to be used here.
+
+Doing it the other way would be extremely expensive to implement. Currently,
+packages are categorized and the check is simply what is the declared category
+of the library unit. You are suggesting that the entire package be analyzed in
+order to make the check. That is a major change in the model of checking for
+these things; I don't think anyone meant to suggest anything that drastic.
+
+In our compiler (and I would suspect most others), "preelaborable" is only
+checked if a categorization requiring it is applied to the library unit. So the
+calculation would have to be inverted, or something. It's a non-starter in my
+view.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 18, 2010 7:51 AM
+
+> In our compiler (and I would suspect most others), "preelaborable" is
+> only checked if a categorization requiring it is applied to the
+> library unit. So the calculation would have to be inverted, or
+> something. It's a non-starter in my view.
+
+That's true of GNAT, though it is something we definitely intend to change,
+since it would be very useful to let a programmer know that pragma Pure or
+Preelaborate *could* be applied to a package.
****************************************************************
Questions? Ask the ACAA Technical Agent