CVS difference for ai05s/ai05-0243-1.txt

--- ai05s/ai05-0243-1.txt	2011/03/17 07:05:20	1.4
+++ ai05s/ai05-0243-1.txt	2011/03/24 05:26:25	1.5
@@ -1,4 +1,4 @@
-!standard 10.2.1(11/3)                              11-03-09    AI05-0243-1/03
+!standard 10.2.1(11/3)                              11-03-23    AI05-0243-1/04
 !standard 10.2.1(17/3)
 !class Amendment 10-10-25
 !status work item  11-02-11
@@ -41,41 +41,58 @@
 Replace 10.2.1(17/3) [as modified by AI05-0034-1 and AI05-0035-1]:
 
 A pragma Pure is used to specify that a library unit is *declared pure*, namely
-that the Pure aspect of the library unit is True. In addition, the limited view
-of any library package is pure. The declaration and body of a declared
+that the Pure aspect of the library unit is True; all compilation units
+of the library unit are declared pure. In addition, the limited view
+of any library package is declared pure. The declaration and body of a declared
 pure library unit, and all subunits that are elaborated as part of elaborating the
 library unit, shall be pure. All compilation units of a declared pure library
-unit shall depend semantically only on compilation units of other pure library
-units, or on a limited view. In addition to the places where Legality Rules
+unit shall depend semantically only on declared pure library_items.
+In addition to the places where Legality Rules
 normally apply (see 12.3), these rules also apply in the private part of an
 instance of a generic unit. Furthermore, the full view of any partial view
 declared in the visible part of a declared pure library unit that has any
 available stream attributes shall support external streaming (see 13.13.2).
 
-AARM Ramification: A limited view never contains any partial views, only
-incomplete views, so the last sentence never applies to a limited view.
+AARM Ramification: A limited view is not a library unit, so any rule that
+starts "declared pure library unit" does not apply to a limited view. In
+particular, the 3rd and last sentences never apply to limited views. OTOH,
+a limited view is a library_item, so rules that discuss "declared pure
+library_items" do include
+
+[Editor's note: We could have said "declared pure compilation unit" instead;
+a limited view should be a compilation unit by 10.1.1(9) -- but since that
+sentence starts "when it is clear from context", I wanted to avoid arguments
+by using "library_item". I extended "declared pure" to all compilation units
+of a library unit to avoid questions about semantic dependencies on bodies
+of declared pure units.
+
+We have to define "declared pure" as it is widely used in the Standard. We also
+need to define limited views as declared pure, so that rules like 10.2(16)
+work (we surely want limited views to elaborate early). I checked all of the
+uses of "declared pure" in the standard, and have suggested changed all that
+need correction in this AI.]
 
 
-
 Replace 10.2.1(11/3) [as modified by AI05-0034-1]:
 
 A pragma Preelaborate (or the pragma Pure -- see below) is used to specify that
-a library unit is *preelaborated*, namely that the Preelaborate aspect of the
-library unit is True. The declaration and body of a
+a library unit is *preelaborated*, namely that the Preelaborate
+aspect of the library unit is True; all compilation units of the
+library unit are preelaborated. The declaration and body of a
 preelaborated library unit, and all subunits that are elaborated as part
 of elaborating the library unit, shall be preelaborable. All
 compilation units of a preelaborated library unit shall depend semantically only
-on compilation units of other preelaborated library units. In
+on declared pure or preelaborated library_items. In
 addition to the places where Legality Rules normally apply (see 12.3), these
 rules also apply in the private part of an instance of a generic unit. If a
 library unit is preelaborated, then its declaration, if any, and body, if any,
 are elaborated prior to all non-preelaborated library_items of the
 partition.
 
-[Editor's note: We need to mention "declared pure" here so that we include
-limited views; these do not necessarily have the Preelaborated aspect set to True.
-If we considered them preelaborated, we're reintroduce the problems that led to
-this AI in the first place.
+[Editor's note: We need to mention "declared pure library_items" here so that we
+include limited views; these do not necessarily have the Preelaborated aspect set
+to True. If we considered them preelaborated, we're reintroduce the problems that
+led to this AI in the first place.
 
 I did check that other uses of "preelaborated" in the standard to ensure that
 this doesn't matter. The only place that is remotely interesting is that this
@@ -83,20 +100,23 @@
 view as per C.4(12) -- this doesn't seem worth changing, as 10.1.1(26.1/2)
 requires that such an elaboration has no effect; if a compiler is executing
 code to have no effect, it has serious problems!
+
+Similarly, with this definition, the implementation advice 10.2.1(12) does not
+apply to a limited view; but since a limited view only includes incomplete views
+which don't have representations, this seems irrelevant.]
 
-Similarly, the implementation advice 10.2.1(12) does not apply to a limited
-view; but since a limited view only includes incomplete views which don't
-have representations, this seems irrelevant.]
 
 In A.3(1/2), replace "pure" with "declared pure".
 
+
+
 Replace E.2(2):
 
-A *categorization aspect* is a operational aspect (see 13.1) that restricts the
+A *categorization pragma* is a library unit pragma (see 10.1.5) that restricts the
 declarations, child units, or semantic dependences of the library unit to which it
-applies. A *categorization pragma* is a library unit pragma (see 10.1.5) that
-specifies a categorization aspect. A categorized library unit is a library unit to
-which a categorization aspect applies.
+applies; each categorization pragma specifies a corresponding *categorization aspect*.
+A *categorized library unit* is a library unit that has a categorization aspect that
+is True.
 
 Replace E.2(3):
 The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization
@@ -109,34 +129,69 @@
 Replace E.2(4/1):
 
 Redundant [A library package or generic library package is called a *shared passive*
-library unit if the Shared_Passive aspect of the unit has the value True. A library package
+library unit if the Shared_Passive aspect of the unit is True. A library package
 or generic library package is called a *remote types* library unit if the Remote_Types aspect
-of the unit has the value True. A library unit package or generic library package is called
-a *remote call interface* if the Remote_Call_Interface aspect has the value True.]
-A *normal library unit* is one for which no categorization aspect has the value True.
+of the unit is True. A library unit package or generic library package is called
+a *remote call interface* if the Remote_Call_Interface aspect is True.]
+A *normal library unit* is one for which no categorization aspect is True.
 
 AARM Proof: These terms are really defined in the following sections.
 
+[Editor's note: I would rather have not talked about the aspects so much here, since
+we're encouraging the use of the pragmas, not the aspects. However, unlike Pure and
+Preelaborated (which have the terms "declared pure" and "preelaborated" that include
+the aspect), we have no corresponding terms to use. Thus we have to talk about the
+aspects; otherwise if we specified the aspect rather than using the pragma we would
+not be able to call the unit "shared passive". Since this is informal text, we
+could cheat here and leave this paragraph unchanged - with a To Be Honest note -
+but I'm unsure that is a good idea -- so I kept this wording from my first attempt.]
+
+Modify E.2(7):
+
+Can depend only on other declared pure library units {and upon limited views};
+
+Modify E.2(8):
+
+Can depend only on other shared passive [or declared pure] library units{; or on one of the above};
+
 Replace E.2.1(4):
 
 A pragma Shared_Passive is used to specify that a library unit is a *shared passive
-library unit*, namely that the Shared_Passive aspect of the library unit is True. The
-following restrictions apply to such a library unit:
+library unit*, namely that the Shared_Passive operational aspect of the library unit
+is True. The following restrictions apply to such a library unit:
 
+Modify E.2.1(6):
+
+it shall depend semantically only upon declared pure or shared passive
+[library units]{library_items}; 
+
+[Editor's note: Necessary because limited views are not library units. Note that
+E.1(3) already says library_items.]
+
 Replace E.2.2(4):
 
 A pragma Remote_Types is used to specify that a library unit is a *remote types
 library unit*, namely that the Remote_Types aspect of the library unit is True.
 The following restrictions apply to such a library unit:
 
+Modify E.2.2(6):
+
+it shall depend semantically only on declared pure, shared passive, or other remote
+types [library units]{library_items};
+
 Replace E.2.3(7/1):
 
 A pragma Remote_Call_Interface is used to specify that a library unit is a *remote call
 interface (RCI)*, namely that the Remote_Call_Interface aspect of the library unit is True.
 The following restrictions apply to such a library unit:
 
-Replace "pragma" with "pragma and aspect" in E.2.3(20).
+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]{library_items}.
+
+Replace "pragma" with "pragma and aspect" in E.2.3(20).
 
 !discussion
 
@@ -169,9 +224,12 @@
 be used in aspect_specifications; all we need to do is define which kind of
 aspects these are.
 
-We define the pragmas to specify the corresponding aspects so that we can
-take advantage of 13.1(9.1): this prevents giving both the pragma and the
-aspect.
+Note that these are neither operational nor representational aspects; neither
+seem to make much sense. This means that 13.1(9-9.1) do not apply; it is OK
+to give both the pragma and the aspect. We don't try to prevent that as there
+isn't any rule that prevents giving two Pure pragmas in a single unit, so it
+doesn't make much sense to make the equivalent aspect/pragma combination
+illegal.
 
 ---