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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0243-1.txt

--- ai05s/ai05-0243-1.txt	2011/02/12 04:29:53	1.1
+++ ai05s/ai05-0243-1.txt	2011/02/15 07:14:33	1.2
@@ -40,7 +40,7 @@
 
 Replace 10.2.1(17/3) [as modified by AI05-0034-1 and AI05-0035-1]:
 
-A pragma Pure sets the Pure operational aspect of the library unit to which it
+A pragma Pure sets the Pure representation aspect of the library unit to which it
 applies to the value True; the aspect can also be set by the aspect_specification
 of the library_item. Setting the Pure aspect on a library unit to True specifies that
 the unit is *declared pure*. In addition, the limited view of a library package is
@@ -62,10 +62,6 @@
 italize the defined term "declared pure", which was not possible with the old
 wording.
 
-We prefer to talk about the aspect being set rather than preferring the pragma,
-because that invokes the rules about setting each aspect only once -- thus
-giving both the pragma and the aspect is illegal.
-
 I would rather talk about the presence or absence of the aspect Pure, but the
 proposed wording for "Boolean pragmas" (of which this is one) talks about
 setting the value to True. These need to be consistent.]
@@ -73,7 +69,7 @@
 
 Replace 10.2.1(11/3) [as modified by AI05-0034-1]:
 
-A pragma Preelaborate sets the Preelaborate operational aspect of the library
+A pragma Preelaborate sets the Preelaborate representation aspect of the library
 unit to which it applies to the value True; the aspect can also be set by the
 aspect_specification of the library_item. If the Preelaborate aspect is set to
 True (or the Pure aspect @emdash see below) for a
@@ -105,8 +101,8 @@
 view; but since a limited view only includes incomplete views which don't
 have representations, this seems irrelevant.]
 
-[Questions:
-(1) It weird that we can write:
+[Question:
+  It weird that we can write:
     package P is
        pragma Pure (P);
        pragma Preelaborate (P);
@@ -114,19 +110,67 @@
     (at least as far as I can tell, I can find no rule banning it);
     it's weirder to be able to write:
     package P
-       with
-          Pure => True,
-          Preelaborate => True is
+       with Pure, Preelaborate is
 
     But there does not appear to be a semantic problem with this, so I didn't
-    make any attempt to ban either form. Should we?
+    make any attempt to ban either form. Should we? Note that we do need
+    multiple categorizations in some cases, so a general rule wouldn't work
+    well - unless we defined a Preelaborated/Remote_Types combo categorization.
+    That's probably too much change. So any added rule would be specific to
+    Pure/Preelaborate.]
+
+Replace E.2(2):
+
+A *categorization aspect* is a representation aspect (see 13.1) 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 sets
+a categorization aspect. A categorized library unit is a library unit to which a
+categorization aspect applies.
+
+Replace E.2(3):
+The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization
+pragmas, and the associated aspects are categorization aspects. In addition, for the
+purposes of this Annex, the aspect Pure (see 10.2.1) is considered a categorization aspect.
+
+[Editor's note: We don't actually need the first sentence, other than that it pulls
+in the library unit pragma rules.]
+
+Replace E.2(4/1):
+
+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 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. 
+
+Replace E.2.1(4):
+
+A pragma Shared_Passive sets the Shared_Passive representation aspect of the
+library unit to which it applies to the value True; the aspect can also be set
+by the aspect_specification of the library_item. Setting the Shared_Passive
+aspect on a library unit to True specifies that the unit is a *shared passive
+library unit*. The following restrictions apply to such a library unit:
+
+Replace E.2.2(4):
 
-(2) It would make sense to apply similar wording to each of the other
-    categorization pragmas. This would require replacing the first sentence
-    of E.2.1(4), E.2.2(4), and E.2.3(7/1) with wording similar to the
-    first two sentences of the new wording above. Should we do this?]
+A pragma Remote_Types sets the Remote_Types representation aspect of the
+library unit to which it applies to the value True; the aspect can also be set
+by the aspect_specification of the library_item. Setting the Remote_Types
+aspect on a library unit to True specifies that the unit is a *remote types
+library unit*. The following restrictions apply to such a library unit:
+
+Replace E.2.3(7/1):
+
+A pragma Remote_Call_Interface sets the Remote_Types representation aspect of the
+library unit to which it applies to the value True; the aspect can also be set
+by the aspect_specification of the library_item. Setting the Remote_Types
+aspect on a library unit to True specifies that the unit is a *remote types
+library unit*. The following restrictions apply to such a library unit:
 
+Replace "pragma" with "aspect" in E.2.3(20).
 
+
 !discussion
 
 The fact that a limited view is considered declared pure should have no effect
@@ -151,6 +195,31 @@
 it or other units). Since we want to define these things as aspects anyway,
 we use that to improve the readability of the rules.
 
+---
+
+We define these as aspects in order to allow them to be specified via an
+aspect_specification. We have a blanket rule allowing library unit pragmas to
+be used in aspect_specifications; all we need to do is define which kind of
+aspects these are.
+
+We define these as a representation aspects so as to take advantage of 13.1(9)
+(which prevents specifying it more than once). (Operational aspects only have
+that rule for types.) This is also why we define the pragma to set the aspect:
+this prevents giving both the pragma and the aspect.
+
+---
+
+Alternative: We could instead define a single aspect called "Categorization",
+and have it take special identifiers Pure, Remote_Types, Shared_Passive, and
+Remote_Call_Interface (and Normal?). Then mapping the pragmas to those values.
+That would enforce that only one of those pragmas could be given per unit.
+
+However, that would leave Preelaborate as the odd man out; it can be usefully
+combined with some of these but not all.
+
+In addition, this would be enforcing a rule which doesn't appear to be enforced
+now, so there would be a small compatibility cost. So this doesn't appear to
+be worthwhile.
 
 
 !corrigendum 10.2.1(11/3)
@@ -168,7 +237,7 @@
 preelaborated, then its declaration, if any, and body, if any, are
 elaborated prior to all non-preelaborated @fa<library_item>s of the partition.
 @dby
-A @fa<pragma> Preelaborate sets the Preelaborate operational aspect of the
+A @fa<pragma> Preelaborate sets the Preelaborate representation aspect of the
 library unit to which it applies to the value True; the aspect can also be set
 by the @fa<aspect_specification> of the @fa<library_item>. If the Preelaborate
 aspect is set to True (or the Pure aspect @emdash see below) for a library unit,
@@ -197,7 +266,7 @@
 the full view of any partial view declared in the visible part of the library
 unit that has any available stream attributes shall support external streaming (see 13.13.2).
 @dby
-A @fa<pragma> Pure sets the Pure operational aspect of the library unit to which
+A @fa<pragma> Pure sets the Pure representation aspect of the library unit to which
 it applies to the value True; the aspect can also be set by the
 @fa<aspect_specification> of the @fa<library_item>. Setting the Pure aspect on a
 library unit to True specifies that the unit is @i<declared pure>. In addition,
@@ -214,24 +283,14 @@
 13.13.2).
 
 
-
-
-A @fa<pragma> Pure is used to declare that a library unit is 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. In addition, the limited view of a
-library package is declared pure. All compilation units of a declared pure
-library unit shall depend semantically only on
-compilation units of other library units that are declared pure. 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 the library
-unit that has any available stream attributes shall support external streaming (see 13.13.2).
-
-
 !ACATS test
 
 No separate ACATS test is needed.
 
+!ASIS
+
+No ASIS effect (as no semantic change is intended).
+
 !appendix
 
 From: Erhard Ploedereder
@@ -976,6 +1035,19 @@
 doubt); we need a real example of a problem, else this complaint should be
 dismissed quickly. (Pascal was never shy about claiming that I was spreading
 FUD, and I think everyone needs to be held to a minimum standard of evidence.)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, February 11, 2011  10:41 PM
+
+Here is the important part of the AI drafted to cover this problem. I'm hesitant
+to even send it because I fear it will lead to a lengthy discussion of how to define
+what "all compilation units of <some library unit>" means (I eliminated this term
+from the wording because it is undefined in the standard, so far as I can tell --
+I checked everything indexed and in related places). Anyway, be gentle...
+
+[Version /01 of the AI follows - Editor.]
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent