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

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

--- ai05s/ai05-0243-1.txt	2011/10/21 06:42:22	1.12
+++ ai05s/ai05-0243-1.txt	2011/11/01 05:32:53	1.13
@@ -1,13 +1,16 @@
-!standard 10.2.1(11/3)                              11-10-14    AI05-0243-1/07
+!standard 10.2.1(11/3)                              11-10-27    AI05-0243-1/08
 !standard 10.2.1(17/3)
 !standard A.3(1/2)
 !standard E.2(2)
 !standard E.2(3)
 !standard E.2(4/1)
+!standard E.2(5)
+!standard E.2(6)
 !standard E.2(7)
 !standard E.2(8)
 !standard E.2(9)
 !standard E.2(10)
+!standard E.2(11)
 !standard E.2.1(4)
 !standard E.2.1(6)
 !standard E.2.2(4)
@@ -138,7 +141,7 @@
 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
-and pragma Pure is considered a categorization pragma.
+and the pragma Pure is considered a categorization pragma.
 
 [Editor's note: We don't actually need the first sentence, other than that it pulls
 in the library unit pragma rules -- and we do need that.]
@@ -163,6 +166,22 @@
 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(5) as modified by AI05-0206-1:
+
+[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 in private with
+clauses{, and all categories can depend on limited views}.
+
+Modify E.2(6):
+The overall hierarchy (including declared pure) is as follows {(with a
+lower-numbered category being earlier in the sense of the previous paragraph)}:
+
+
 Modify E.2(7):
 
 Can depend only on other declared pure library units {or upon limited views};
@@ -372,7 +391,7 @@
 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
-and pragma Pure is considered a categorization pragma.
+and the pragma Pure is considered a categorization pragma.
 
 !corrigendum E.2(4/1)
 
@@ -387,51 +406,71 @@
 A library package or generic library package is called a @i<shared passive>
 library unit if the Shared_Passive aspect of the unit is True. A library package
 or generic library package is called a @i<remote types> library unit if the Remote_Types aspect
-of the unit is True. A library unit package or generic library package is called
-a @i<remote call interface> if the Remote_Call_Interface aspect is True.
+of the unit is True. A library unit is called
+a @i<remote call interface> if the Remote_Call_Interface aspect of the unit is True.
 A @i<normal library unit> is one for which no categorization aspect is True.
 
-!corrigendum E.2(7)
+!corrigendum E.2(5)
 
 @drepl
-@xhang<@xterm<Declared Pure>Can depend only on other declared pure library units;>
+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.
 @dby
-@xhang<@xterm<Declared Pure>Can depend only on other declared pure library units
-or upon limited views;>
+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, the
+declaration of a remote types or remote call interface library unit may depend
+on preelaborated normal library units that are mentioned only in private with
+clauses, and all categories can depend on limited views.
 
-!corrigendum E.2(8)
+!corrigendum E.2(6)
 
 @drepl
-@xhang<@xterm<Shared Passive>Can depend only on other shared passive or declared
-pure library units;>
+The overall hierarchy (including declared pure) is as follows:
 @dby
+The overall hierarchy (including declared pure) is as follows (with a
+lower-numbered category being earlier in the sense of the previous paragraph):
+@xindent<1) Declared Pure>
+@xindent<2) Shared Passive>
+@xindent<3) Remote Types>
+@xindent<4) Remote Call Interface>
+@xindent<5) Normal (no restrictions)>
+
+!corrigendum E.2(7)
+
+@ddel
+@xhang<@xterm<Declared Pure>Can depend only on other declared pure library units;>
+
+!corrigendum E.2(8)
+
+@ddel
 @xhang<@xterm<Shared Passive>Can depend only on other shared passive or declared
-pure library units, or upon limited views;>
+pure library units;>
 
 !corrigendum E.2(9)
 
-@drepl
+@ddel
 @xhang<@xterm<Remote Types>
 The declaration of the library unit can depend only on other remote types library
 units, or one of the above; the body of the library unit is unrestricted;>
-@dby
-@xhang<@xterm<Remote Types>
-The declaration of the library unit can depend only on other remote types library
-units, or any of the above library unit categories, or limited views;
-the body of the library unit is unrestricted;>
 
 !corrigendum E.2(10)
 
-@drepl
+@ddel
 @xhang<@xterm<Remote Call Interface>
 The declaration of the library unit can depend only on other remote call
 interfaces, or one of the above; the body of the library unit is
 unrestricted;>
-@dby
-@xhang<@xterm<Remote Call Interface>
-The declaration of the library unit can depend only on other remote call
-interfaces, or any of the above library unit categories, or limited views;
-the body of the library unit is unrestricted;>
+
+!corrigendum E.2(11)
+
+@ddel
+@xhang<@xterm<Normal>Unrestricted.>
 
 !corrigendum E.2.1(4)
 
@@ -439,7 +478,7 @@
 A @i<shared passive library unit> is a library unit to which a Shared_Passive pragma applies.
 The following restrictions apply to such a library unit: 
 @dby
-A pragma Shared_Passive is used to specify that a library unit is a @i<shared passive
+A @fa<pragma> Shared_Passive is used to specify that a library unit is a @i<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:
 
@@ -458,9 +497,9 @@
 A @i<remote types library unit> is a library unit to which the pragma Remote_Types applies. The
 following restrictions apply to the declaration of such a library unit:
 @dby
-A pragma Remote_Types is used to specify that a library unit is a @i<remote types
+A @fa<pragma> Remote_Types is used to specify that a library unit is a @i<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:
+The following restrictions apply to the declaration of such a library unit:
 
 !corrigendum E.2.2(6)
 
@@ -477,8 +516,8 @@
 A @i<remote call interface (RCI)> is a library unit to which the pragma Remote_Call_Interface
 applies. A subprogram declared in the visible part of such a library unit, or declared by
 such a library unit, is called a @i<remote subprogram>.
-@drepl
-A pragma Remote_Call_Interface is used to specify that a library unit is a @i<remote call
+@dby
+A @fa<pragma> Remote_Call_Interface is used to specify that a library unit is a @i<remote call
 interface (RCI)>, namely that the Remote_Call_Interface aspect of the library unit is True.
 A subprogram declared in the visible part of such a library unit, or declared by
 such a library unit, is called a @i<remote subprogram>.
@@ -1669,5 +1708,154 @@
 Yes, bully for the ancience Greeks and their interesting language (with which I
 am quite familiar), but still i ask, what on earth does this have to do with
 english? :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, October 15, 2011  12:27 AM
+
+[Editor's note: This was a private editorial thread; the important parts
+are quoted here.]
+
+...
+> >> E.2 (8/3) "One of the above" is confusing. Does that mean you can 
+> >> only depend on one declared pure library unit or limited view, or 
+> >> only on either declared pure library units or limited views, or the 
+> >> intended meaning.
+> >> This is confusing partly because there is only one above. It would 
+> >> be clearer to say;
+> >>
+> >> "Can depend only on other shared passive {units, } library units{, 
+> >> or limited views}"
+> > But that doesn't work by itself, because 9/3 and 10/3 also use the 
+> > "one of the above" wording (and always have), and that wording also 
+> > has to include limited views.
+> >
+> > We could add "limited views" to all four items (individually), but 
+> > that would look ridiculous. If we did that, we would have to 
+> > eliminate the "one of the above" wording (probably we ought to do 
+> > that in any case because of the unrelated AI05-0206-1 changes).
+> I think the "one of the above" is completely wrong from the get go, 
+> because if there is more than one above, a library unit can depend on 
+> more than one of the above. If there is only one above (Shared 
+> Passive), it doesn't make sense to say one of the above, because there 
+> only is one of the above.
+> 
+> However, I don't think repeating limited views is ridiculous. 
+> It's only a few words repeated in a 3 places, and if it captures the 
+> meaning, then its good enough in my mind.
+> 
+> e.g.,
+> 
+> 8/3
+> "Can depend only on other shared passive or declared pure library 
+> units, and upon limited views;"
+> 
+> 9/3
+> "The declaration of the library unit can depend only on other remote 
+> types library units, or {any}[one] of the above{library unit 
+> categories, or limited views, }or preelaborated normal library units 
+> that are mentioned only in private with clauses;"
+> 
+> 10/3
+> "The declaration of the library unit can depend only on other remote 
+> call interfaces, or {any}[one] of the above {library unit categories, 
+> or limited views}, or preelaborated normal library units that are 
+> mentioned only in private with clauses"
+> 
+> I recall I found having the hierarchy here was helpful, when I was 
+> getting my head wrapped around Annex E.
+
+I can believe that the hierarchy is important to understanding. I've made your
+recommended changes, but I don't think that they are a good idea.
+That's because I think you've lost sight of the big picture. The reason the
+Ada 95 hierarchy was useful was because it was a very short visual description
+of the relationships of the categories. (And that's the version that you read
+and found useful.)
+
+But lately, you (and others) have been obsessed with having this text be exactly
+correct, meaning it has to describe all of the exceptions to the rules. The problem
+is, we've added a whole bunch of them, and all of that extra text makes it a lot
+harder to understand the IMPORTANT dependencies between the categories. The net
+effect is that it is a lot less useful now than it was originally. Indeed, now it
+is mostly a language maintenance hazard, because it mostly repeats rules given
+(and updated) elsewhere.
+
+However, I give up. I can't seem to get anyone to understand that this has devolved
+into an unintelligible mess (I thought it was too hard to understand in its Ada 95
+version, and it is now much worse), and this Annex simply isn't important enough
+to spend extra energy on.
+
+> > But this is all "redundant" text - the actual definitions are 
+> > elsewhere, and another solution is to simply delete the entirety of 
+> > E.2(5-12). It is getting too hard to keep this text accurate. A less
+> > nuclear option is to somehow "soften" this wording so it is 
+> > crystal-clear that it doesn't provide any definition of what you can
+> > do, just a general hierarchy. But I'm not sure how to do that.
+> >
+> > So I didn't do anything here for now. I agree that*something* needs
+> > to be changed, but your suggestion leaves 9/3 and 10/3 broken 
+> > vis-a-vis limited views (if they don't apply to "one of the above" in
+> > 8/3, they surely don't in 9/3 or 10/3 either). I'd much prefer to get
+> > all of the technical information out of here; it is insane to 
+> > essentially repeat the detailed definition of these categories here.
+> >
+> > Perhaps just giving the hierarchy and nothing else would be best??
+> > (Especially as 5/3 already explains the details in a general way.) Say:
+> >
+> > The overall hierarchy (including declared pure) is as follows (with a
+> > lower-numbered category being earlier in the sense of the previous
+> > paragraph):
+> >        1) Declared Pure
+> >        2) Shared Passive
+> >        3) Remote Types
+> >        4) Remote Call Interface
+> >        5) Normal (no restrictions)
+> >
+> > [A bulleted list would be inappropriate here, as the item order is 
+> > significant. I'm not a fan of the numbers, but that's pretty much the
+> > only other choice we have.]
+> >
+> > Is that OK? Any better ideas? Ideas are welcome as this is fairly 
+> > significant change.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, October 15, 2011  12:27 AM
+
+> However, I give up. I can't seem to get anyone to understand that this 
+> has devolved into an unintelligible mess (I thought it was too hard to 
+> understand in its Ada 95 version, and it is now much worse), and this 
+> Annex simply isn't important enough to spend extra energy on.
+
+My most recent suggested wording was about how to fix what we have with minimal
+correction so that it addressed the problems initially raised, as well as your
+concerns about my prior suggested wording. I do see your point as well though,
+and I agree with you.
+
+How about:
+
+5/3
+[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 in private with
+clauses{, and all categories can depend on limited views}.
+
+6/3
+The overall hierarchy (including declared pure) is as follows {(with a
+lower-numbered category being earlier in the sense of the previous paragraph):
+
+1) Declared Pure
+2) Shared Passive
+3) Remote Types
+4) Remote Call Interface
+5) Normal (no restrictions)
+
+I think this is better
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent