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

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

--- ai05s/ai05-0243-1.txt	2011/02/16 01:15:32	1.3
+++ ai05s/ai05-0243-1.txt	2011/03/17 07:05:20	1.4
@@ -1,6 +1,6 @@
-!standard 10.2.1(11/3)                              11-02-15    AI05-0243-1/02
+!standard 10.2.1(11/3)                              11-03-09    AI05-0243-1/03
 !standard 10.2.1(17/3)
-!class binding interpretation 11-02-11
+!class Amendment 10-10-25
 !status work item  11-02-11
 !status received 11-02-11
 !priority Medium
@@ -27,7 +27,7 @@
 library unit. But this would obliterate most of the usefulness of limited views
 of lib.units, since the real units would need to be pure.
 
-That can't be intended. What is the intent? (Anything but that.)
+That can't be intended. What is the intent?
 
 !recommendation
 
@@ -40,45 +40,32 @@
 
 Replace 10.2.1(17/3) [as modified by AI05-0034-1 and AI05-0035-1]:
 
-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
-declared pure. The declaration and body of a library unit with the Pure aspect
-set to True, and all subunits that are elaborated as part of elaborating the
-library unit, shall be pure. The declaration and body of a library unit with the
-Pure aspect set to True, and all subunits of the 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
-a declared pure library unit that has any available stream attributes shall
-support external streaming (see 13.13.2).
+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
+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
+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.
 
-[Editor's notes: A nice side-effect of this rewording is that we can
-italize the defined term "declared pure", which was not possible with the old
-wording.
-
-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.]
 
 
 Replace 10.2.1(11/3) [as modified by AI05-0034-1]:
 
-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
-(or the Pure aspect @emdash see below) is set to True for a library unit, then
-the library unit is *preelaborated*. The declaration and body of a
+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
 preelaborated library unit, and all subunits that are elaborated as part
-of elaborating the library unit, shall be preelaborable. In addition, the
-limited view of a library package is preelaborated. All
+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 or declared pure library units. In
+on compilation units of other preelaborated library units. 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,
@@ -86,9 +73,9 @@
 partition.
 
 [Editor's note: We need to mention "declared pure" here so that we include
-limited views; these do not have the Pure aspect set to True. If we considered
-them preelaborated, we're reintroduce the problems that led to this AI in the
-first place.
+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
@@ -101,31 +88,15 @@
 view; but since a limited view only includes incomplete views which don't
 have representations, this seems irrelevant.]
 
-[Question:
-  It weird that we can write:
-    package P is
-       pragma Pure (P);
-       pragma Preelaborate (P);
-
-    (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, 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? 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.]
+In A.3(1/2), replace "pure" with "declared pure".
 
 Replace E.2(2):
 
-A *categorization aspect* is a representation aspect (see 13.1) that restricts the
+A *categorization aspect* is a operational 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.
+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.
 
 Replace E.2(3):
 The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization
@@ -137,38 +108,34 @@
 
 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.
+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
+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.
 
+AARM Proof: These terms are really defined in the following sections.
+
 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:
+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:
 
 Replace E.2.2(4):
 
-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:
+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:
 
 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:
+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 "aspect" in E.2.3(20).
+Replace "pragma" with "pragma and aspect" in E.2.3(20).
 
 
 !discussion
@@ -202,10 +169,9 @@
 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.
+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.
 
 ---
 
@@ -1054,18 +1020,45 @@
 From: Erhard Ploedereder
 Date: Tuesday, February 15, 2011  6:17 PM
 
-I think that Randy's rewording works. I have small editorials; markups are relative to Randy's wording.
+I think that Randy's rewording works. I have small editorials; markups are
+relative to Randy's wording.
 
 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 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 declared pure. The declaration and body of a library unit with the Pure aspect set to True, and all subunits that are elaborated as part of elaborating the library unit, shall be {d
eclared} pure. The declaration and body of a library unit with the Pure aspect set {to} True, and all subunits of the 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 a declared pure lib
-ry unit that has any available stream attributes shall support external streaming (see 13.13.2).
+A pragma Pure sets the Pure operational 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 declared pure. The declaration and
+body of a library unit with the Pure aspect set to True, and all subunits
+that are elaborated as part of elaborating the library unit, shall be
+{declared} pure. The declaration and body of a library unit with the Pure
+aspect set {to} True, and all subunits of the 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 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 never contains any partial views, only
+incomplete views, so the last sentence never applies to a limited view.
 
 Replace 10.2.1(11/3) [as modified by AI05-0034-1]:
 
-A pragma Preelaborate sets the Preelaborate operational 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 library unit {is set to True}, then [it]{the library unit} is *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. In addition, the limited view of a library package is preelaborated. All compilation units of a preelaborated library unit shall depend semantically only on compilation units of other preelaborated or declared pure library units.  In additio
n 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,
+A pragma Preelaborate sets the Preelaborate operational 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 library unit {is set
+to True}, then [it]{the library unit} is *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. In addition, the
+limited view of a library package is preelaborated. All compilation units of a
+preelaborated library unit shall depend semantically only on compilation units
+of other preelaborated or declared pure library units.  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,
 e elaborated prior to all non-preelaborated library_items of the partition.
 
 ****************************************************************
@@ -1130,3 +1123,196 @@
 
 ****************************************************************
 
+From: Erhard Ploedereder
+Date: Wednesday, February 15, 2011  12:57 AM
+
+> > Replace 10.2.1(17/3) [as modified by AI05-0034-1 and AI05-0035-1]:
+> ...
+> > and all subunits that are elaborated as part of elaborating the
+> > library unit, shall be {declared} pure. The declaration and body of
+> > a library unit with the Pure aspect set
+> ...
+
+> This change is wrong, although it surely is confusing. The difference
+> between a library unit that is "pure" and one that is "declared pure"
+> is similar to the difference between a unit that is "preelaborable"
+> and one that is "preelaborated".
+
+You are right. Oh my. A good one for the Rat-ier to explain.
+
+> >PS. There are couple of places in the RM where "pure" -> "declared
+> >pure"
+> >A.3(1/2)
+> >E.2.2 (18)
+
+> I think these are OK as they are, because in the first case either
+> term fits fine, and in the second case, it really means "pure" and not
+> "declared pure".
+
+Agree for E.2.2 (18). Disagree somewhat for A.3(1/2), because a declared
+pure pkg can semantically depend on a declared pure package Characters,
+but cannot depend on a pure package Characters, as per the rules.
+Sure, the packages turn out to be declared pure as well by virtue of the
+pragma, but why not say so?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Saturday, February 19, 2011  5:06 PM
+
+  Modify 10.2.1(17/3) as follows:
+
+  A pragma Pure is used to specify that a library unit is pure, namely
+  that the Pure aspect of the library unit is True. The declaration and
+  body of a pure library unit, and all subunits that are elaborated as
+  part of elaborating the library unit, shall be pure.  [Redundant: The
+  limitive view of any library package is pure.]  All compilation units
+  of a pure library unit shall depend semantically only on compilation
+  units of other pure library units[Redundant:, or on a limited view.] In
+  addition to the places where Legality Rules normally apply (see 12.3),
+  this rule also applies 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 pure library unit that has any available stream
+  attributes shall support external streaming (see 13.13.2).
+
+****************************************************************
+
+From: Steve Baird
+Date: Saturday, February 19, 2011  6:01 PM
+
+>  Modify 10.2.1(17/3) as follows:
+>
+>  A pragma Pure is used to specify that a library unit is pure, namely
+> that the Pure aspect of the library unit is True.
+
+A pragma Pure is used to specify that the Pure aspect of a library unit is True; such a library unit is said to be Pure.
+
+>  The declaration and
+>  body of a pure library unit, and all subunits that are elaborated as
+> part of elaborating the library unit, shall be pure.  [Redundant: The
+> limitive view of any library package is pure.]
+
+Typo: "limitive" => "limited".
+
+I will admit that limitive aspectizing sounds intriguing.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Saturday, February 19, 2011  6:28 PM
+
+> Typo: "limitive" =>  "limited".
+>
+> I will admit that limitive aspectizing sounds intriguing.
+
+Hmm, I thought it sounded intriverating.
+
+****************************************************************
+
+From: John Barnes
+Date: Sunday, February 20, 2011  7:15 AM
+
+I am happy with this new wording. Rather neat.  Indeed quite intriverated.
+
+Could do it for pragma CPU as well!
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 10, 2011  12:46 AM
+
+>   Modify 10.2.1(17/3) as follows:
+>
+>   A pragma Pure is used to specify that a library unit is pure, namely
+>   that the Pure aspect of the library unit is True. The declaration and
+>   body of a pure library unit, and all subunits that are elaborated as
+>   part of elaborating the library unit, shall be pure. [Redundant: The
+>   limitive view of any library package is pure.]  All compilation units
+>   of a pure library unit shall depend semantically only on compilation
+>   units of other pure library units[Redundant:, or on a limited view.] In
+>   addition to the places where Legality Rules normally apply (see 12.3),
+>   this rule also applies 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 pure library unit that has any available stream
+>   attributes shall support external streaming (see 13.13.2).
+
+There are two problems with this wording.
+
+First, there are more than 30 occurrences of "declared pure" in the Standard.
+This wording removes the defined term (which unfortunately is not clearly
+defined in the old wording) and a couple of uses. But you cannot be seriously
+implying that we need to change all of those other uses to something else. (And
+nothing else makes sense; "pure" is not quite the same as "the Pure aspect of
+the library unit is True".) That would be churning the standard's wording to no
+end (we're not really changing anything about this term).
+
+I'd suggest leaving the word "declared" in the first two sentences to fix this
+without changing the entire world:
+
+>   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. 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. ...
+
+[I'm not sure why we were trying to get rid of this term anyway, it doesn't help
+anything to "pure library unit" for "declared pure"; they both are different
+from "pure" by itself, so the reason for the confusion still remains. And
+rewriting 30 other places it not worth a minor improvement in the wording.]
+
+The other issue is why you have the sentence "[Redundant: The limited view of
+any library package is pure.]" marked as redundant. This has to be formally
+defined somewhere! But I don't know of any place where this is defined. A
+similar comment exists for the latter text that is marked as redundant: if you
+don't include it, you couldn't have any dependence on a limited view (as it is
+not a library unit). That doesn't seem redundant to me!
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, March 10, 2011  1:25 AM
+
+> There are two problems with this wording.
+
+This is much worse than I thought.
+
+A minor additional problem is that the wording
+
+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.
+
+bizarrely switches from plural to singular. Apparently, a pure unit can only
+depend on one limited view (not two). It's also weird that the first part goes
+into excruciating detail and the last part doesn't even mention unit.
+
+But the more important problem is that a limited view is not a library unit (as
+we decided at the meeting). That's not a problem here, but in many of the
+existing uses of "declared pure". For instance, E.2.1(6): "it shall depend
+semantically only on declared pure or shared passive library units."
+
+The original "fix" was to say that a limited view is declared pure. But since it
+is not a library unit, arguably the previous statement doesn't apply to limited
+views. That surely was not intended.
+
+That means we have to go through the entire freaking standard and change every
+discussion of "semantic dependence" to explicitly mention "limited views". The
+good thing is we can drop any mention of limited views being "pure" or
+"preelaborated", since they'll be explicitly listed everywhere -- so Erhard's
+original problem vanishes. But if we do that, we then have to rewrite 10.2(16),
+since "declared pure" library items would not include limited views, but still
+would have an elaboration dependence on them (thus there would be no order that
+would meet 10.2(18)).
+
+I also have to wonder why the Pure wording says "compilation units of declared
+pure library units". (This was true even in Ada 95.) If there is some other
+non-library unit that we can depend upon (and this is not verbal diarrhea), then
+all of the Annex E wording does not work (as it only refers to library units)
+and needs to be fixed. Otherwise, we should simplify the Pure and Preelaborate
+wording.
+
+So at this point, I don't know what to do. The meeting implied that rewriting a
+large number of part of the standard was needed (30+ occurrences, in 17
+different clauses), and that is insane. But now it appears to me that a bunch of
+those references are garbage anyway (at least 4). Please give me some indication
+of what you think the correct path is.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent