!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 !status received 11-02-11 !priority Medium !difficulty Easy !qualifier Omission !subject Clarification of categorizations !summary Categorizations like Pure, Preelaborate, etc. are aspects. A limited view of a unit is considered declared pure; this does not impose any restrictions on any unit associated with the "regular" view of the unit. !question The wording proposed by AI05-0034-1 and AI05-0035-1 starts: A 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. ... Clearly the second sentence would apply to the body of the limited-viewed 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? !recommendation (See summary.) !wording [Editor's note: These are given backwards here because we need to understand the rules for Pure before we can talk meaningfully about Preelaborate.] 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; 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 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 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; 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 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 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 would not require any documentation of code executed to elaborate a limited 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.] In A.3(1/2), replace "pure" with "declared pure". Replace E.2(2): 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; 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 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): Redundant [A library package or generic library package is called a *shared passive* 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 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 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: 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 The fact that a limited view is considered declared pure should have no effect on any compilation unit of the "regular" view. The only units that have requirements applied to them are those that that actually contain a pragma Pure or are non-limited units that are related (bodies and subunits). One of the problems here is that the term "all compilation units of" some unit is not defined by the standard. We presume this includes all subunits, but there is no evidence in the standard itself to confirm this view. In addition, it is certainly arguable that that this would include the limited view, but clearly we do not want that in this case. So we need to eliminate this wording. Similarly, we do not want to be talking about any other units of a limited view -- what exactly is the body or declaration of a limited view? There are a lot of opinions on this topic (see the !appendix if you care) and it is easier to just craft the rules we want without answering such questions. Thus, there needs to be a differentiation between units that have purity requirements and units that are pure by definition (with no requirements on 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. 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. --- 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) @drepl If a @fa Preelaborate (or @fa Pure @emdash see below) applies to a library unit, then it 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 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, are elaborated prior to all non-preelaborated @fas of the partition. @dby A @fa 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 of the @fa. If the Preelaborate aspect (or the Pure aspect @emdash see below) is set to True for a library unit, then the library unit is @i. 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, are elaborated prior to all non-preelaborated @fas of the partition. !corrigendum 10.2.1(17/3) @drepl A @fa 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). @dby A @fa 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 of the @fa. Setting the Pure aspect on a library unit to True specifies that the unit is @i. 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). !ACATS test No separate ACATS test is needed. !ASIS No ASIS effect (as no semantic change is intended). !appendix From: Erhard Ploedereder Date: Saturday, October 9, 2010 10:39 AM As part of the document review, I stumbled over a technical issue. I am separating this issue into a mail separate from the more routine review results. Here is my review comment on 10.2.1 11/3 and 17/3, where preelaborated and pure views of library units are a new (and unneeded) concept. Particularly, pure views seem to require that the bodies of the units be pure as well, which is presumably not the intent (according to the AI). ======================== 10.2.1. 11/3 > If a pragma Preelaborate (or pragma Pure see below) applies to a > library unit, then it 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 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, are elaborated prior to all > nonpreelaborated library_items of the partition. Editorial: I would prefer if 2. and 3. sentence were exchanged, so that we have the complete list of preelaborated units, before their properties are explained. Content: I am not sure that views should have the property of preelaborated construct (which construct?). It really sticks out (note also the analogous comment on "pure", where the situation is even worse). I realize that this is late, but here would be a rewrite that takes care of it and reflects the summary of AI-34 almost verbatim..... All I did was to make the necessary allowances for dependencies on limited views, in lieu of extending "preelaborated" (and "pure") to views. Rewrite: ------------ If a pragma Preelaborate (or pragma Pure see below) applies to a library unit, then it 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. All compilation units of a preelaborated library unit shall depend semantically only on compilation units of other preelaborated library units or limited views of 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, are elaborated prior to all nonpreelaborated library_items of the partition. ============================================= 10.2.1 17/3 > A 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 .... Editorial: Analogous comment as for 11/3. Content: Here I have a real problem. Clearly the old 2. sentence would apply to the body of the limited-viewed library unit, would it not? But this would obliterate most of the usefulness of limited views of lib.units, since the real units would need to be pure. Rewrite: -------- A 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. All compilation units of a declared pure library unit shall depend semantically only on compilation units of other library units that are declared pure or on limited views of library units. In addition to the places ... =========================== And should the ARG decide not to fix in the proposed direction, here are the editorial rewrites that exchance 2. and 3. sentence. The issue of the pure bodies for limited views I then leave to someone else to fix. Rewrite for 10.2.1. 11/3: ----- If a pragma Preelaborate (or pragma Pure see below) applies to a library unit, then it is preelaborated. In addition, the limited view of a library package 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. All compilation units of a preelaborated library unit shall depend semantically only ..... ----- Rewrite for 10.2.1. 17/3: ------ A pragma Pure is used to declare that a library unit is pure. In addition, the limited view of a 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 library units that are declared pure. In addition to the places ... ------- **************************************************************** From: Randy Brukardt Date: Friday, January 28, 2011 9:15 PM ... > 10.2.1 17/3 > > > A 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 .... > > Editorial: > Analogous comment as for 11/3. > Content: > Here I have a real problem. Clearly the old 2. sentence would apply to > the body of the limited-viewed library unit, would it not? > But this would obliterate most of the usefulness of limited views of > lib.units, since the real units would need to be pure. I don't buy this argument, because (a) the order of the wording is significant and (b) a limited view doesn't have a body or any other defined connection to the "regular" view of a unit. But I do realize that it could be misleading. > Rewrite: > -------- > A 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. All compilation units of a declared pure library unit > shall depend semantically only on compilation units of other library > units that are declared pure or on limited views of library units. In > addition to the places ... This rewrite is a really bad idea. Annex E is filled with wording that talks about dependence on "declared pure" units, and rewriting all of that to say "declared pure or limited view" does not seem like a very good idea. Some examples: E.2(7-8), E.2.1(6), and E.2.2(6). I'd rather leave the wording alone and add a Ramification or To Be Honest note. Or perhaps add "considered" (to point out that it doesn't have any other effect) along with an AARM note. "In addition, the limited view of a library package is {considered} declared pure." **************************************************************** From: Bob Duff Date: Saturday, January 29, 2011 8:22 AM > I'd rather leave the wording alone and add a Ramification or To Be > Honest note. I agree with that. >...Or perhaps add "considered" (to point out that it doesn't have any >other effect) along with an AARM note. > > "In addition, the limited view of a library package is {considered} > declared pure." I don't think "considered" adds anything. **************************************************************** From: Erhard Ploedereder Date: Saturday, January 29, 2011 5:16 PM ... > > Content: > > Here I have a real problem. Clearly the old 2. sentence would apply > > to the body of the limited-viewed library unit, would it not? > > But this would obliterate most of the usefulness of limited views of > > lib.units, since the real units would need to be pure. > I don't buy this argument, because (a) the order of the wording is > significant and (b) a limited view doesn't have a body or any other > defined connection to the "regular" view of a unit. But I do realize > that it could be misleading. > ....perhaps add "considered" .... > "In addition, the limited view of a library package is {considered} > declared pure." The "considered" is a good idea in any case. But my problem was less with the fact that no Pragma Pure was applied, but rather with something else: > and (b) a limited view doesn't have a body ... It is rather hard to conclude from the RM that the body of the completing library unit is not a body of its limited view as well. I certainly thought the opposite. Could we make that more explicit somewhere? ("A limited view is considered to not have a body." right before or after 12.6./2) > ... or any other defined connection to the "regular" view of a unit. That's not true. See 10.1.1, 26/2, 4. sentence: a unit depends on its limited view. But this does not matter in this context. And 12.6(2): a library unit decl completes its limited view. **************************************************************** From: Randy Brukardt Date: Saturday, January 29, 2011 9:28 PM Sorry, wasn't specific enough. I wasn't talking about semantic dependence or completion, that isn't relevant when talking about rules like this. I specifically thinking that a limited view is its own thing, and it isn't a body or a specification or a subunit or anything else. It is a completely separate thing. It is only connected to those other things by dependence relationships. If it had a body, it would be empty (given the definition of what appears in a limited view), and it wouldn't be the same body as the one the unit itself has. But there isn't much point in talking about that. But I agree that the standard isn't clear about this either way. Going back to the actual wording, I note that 10.2.1(17/2) [the Ada 2005 wording] talks about rules that apply only when "a pragma Pure" applies to a library unit. That would provide another solution to this problem (as "declared pure" can be something else then). Consider: A pragma Pure is used to declare that a library unit is pure. The declaration and body of a [declared pure] library unit{ to which pragma Pure applies}, 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 {considered} 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 .... Here we make the pure requirement on the library units in which pragma Pure applies, their bodies and subunits. We then say that the limited view is *also* declared pure. Then the next rule applies to all "declared pure" units. Net effect is that we have slightly different rules for "pragma Pure applies" and "considered declared pure", and there is no confusion as to which is which. Perhaps this is a better solution, as it hopefully wouldn't cause people to argue as to whether or not a limited view has any effect on the regular body. Note however that we can't then reorder this wording as you had suggested, as it would be bizarre to mix up the limited view stuff with the stuff that only applies to "regular" units. **************************************************************** From: Erhard Ploedereder Date: Wednesday, February 2, 2011 6:01 PM While I am not disagreeing with your message, rather than rewformulating the paragraph, would it not be a lot simpler to simply a) add "A limited view is considered to not have a body." right before or after 12.6.2 (or simpler still: "A limited view does not have a body.") and b) "In addition, the limited view of a library package is {considered} declared pure." in the para in question. Both changes are true statements (in some people's view a) is a derivable statement) and we have answered my concern. **************************************************************** From: Randy Brukardt Date: Wednesday, February 2, 2011 7:16 PM I don't think so, because the reading you described is reasonable and it surely isn't clear either way from the standard what "its compilation units" are. Adding some text about the body would help that, but the expansive view of "its units" includes the regular specification along with the regular body. (If you are going to include one, you have to include the other.) And you also would include all of the subunits of the unit. If you want to fix this without changing 10.2.1(17), then you have to properly define what "its compilation units" are WRT to limited views. That seems like a lot more work (and it would be bizarre as well) than either adding a To Be Honest to ensure no one ever thinks like you, or rewording to make sure that the limited view case is completely separate from the "its compilation unit case". (To say that a limited view is not associated with any compilation units is weird because it obviously came from one. Once you say that it IS associated with any units, the trouble begins.) I think it was always the intent that limited views are pure by fiat; there was no intent that anyone would try to apply sentence 2 to limited views. But it appears that you ought to do that, at least in one reading. That needs to be addressed somehow. **************************************************************** From: Bob Duff Date: Thursday, February 3, 2011 9:40 AM I haven't followed this conversation in detail, but I really think "A limited view does not have a body." can only make sense to the most legalistic of language lawyers. Of course it has a body, if I wrote "package body P is..." There's got to be a better way fix the problem. Perhaps "To Be Honest". **************************************************************** From: Jean-Pierre Rosen Date: Thursday, February 3, 2011 9:57 AM IIUC, the /package/ has a body, but the body is not included in the /view/. Maybe something like: "A limited view does not include/cover/extend to/.... the body of the package (if any)". **************************************************************** From: Tucker Taft Date: Thursday, February 3, 2011 1:59 PM That sounds reasonable. **************************************************************** From: Randy Brukardt Date: Thursday, February 3, 2011 3:09 PM That would work for bodies, but it doesn't really address the real question, which is "what are the compilation units of a limited view?". This not only includes the body, but also the normal specification, and (because of other wording) subunits. (I'm not sure that "all of its compilation units" is well-defined in the first place, even for a library unit.) But since we don't have to answer this question in the first place, why struggle to get it right? Just make it clear that a limited view is considered to be declared pure without any requirement on any other unit or view. I've suggested at least three ways to do that, and people keep trying to answer the tough question instead. **************************************************************** From: Bob Duff Date: Thursday, February 3, 2011 3:17 PM I agree with your approach -- don't answer the tough question. No strong opinion on how to go about not doing so. **************************************************************** From: Edmond Schonberg Date: Monday, February 7, 2011 11:13 AM > I haven't followed this conversation in detail, but I really think "A > limited view does not have a body." > can only make sense to the most legalistic of language lawyers. Of > course it has a body, if I wrote "package body P is..." I don't see this at all. We are speaking about a "view" and a limited view is an extremely narrow window into a package, that allows to you see a minimum of details. It does not let you see the body, so the view has no body. **************************************************************** From: Bob Duff Date: Monday, February 7, 2011 11:37 AM But you could say the same thing about a package spec. It doesn't let you see the body, but it "has" one, by which I mean, informally, that there is a body corresponding to that spec (usually). If we have: package P is ... end; package body P is ... end; -- (*) limited with P; package ... There is a limited view of P, and it seems to me that "this view has no body" is denying the existence of (*). That seems like a roundabout/confusing way of saying what we're trying to say, which is that from that limited view, we can't see the rest of the package (spec and body), so we don't care about those for the purposes of what you're allowed to put in a declared-Pure thing. Now do you see what I mean? **************************************************************** From: Tucker Taft Date: Monday, February 7, 2011 11:51 AM I don't see your point, Bob. A limited view of a package looks quite different than the full view, in that it has only incomplete types and nested packages, and it omits nested package instances, and various other things. So saying that the limited view omits the body completely seems reasonable. Originally we considered having an explicit partial declaration of a package (called a package "abstract" if I remember), and that morphed into creating this partial declaration automatically in response to a limited with clause. This package "abstract," or this "limited view," is essentially a partial declaration of the package. Yes, the *package* has a body, but the "limited view" does not have a body. It is just a bunch of incomplete type declarations. **************************************************************** From: Bob Duff Date: Monday, February 7, 2011 12:06 PM > I don't see your point, Bob. So either: You and Ed are what I called "the most legalistic of language lawyers". Or: It's just me, who has an oddball point of view. >... A limited > view of a package looks quite different than the full view, in that >it has only incomplete types and nested packages, and it omits nested >package instances, and various other things. So saying that the >limited view omits the body completely seems reasonable. I agree it makes sense to say the limited view omits the body. Somehow "omits" makes sense to me, where "does not have" confuses -- the latter (to me) means "does not have a corresponding". > Originally we considered having an explicit partial declaration of a > package (called a package "abstract" if I remember), ... Right, and if we had gone that way, I'd feel the same way -- the abstract does not contain the body (it omits the body -- and the spec for that matter), but it HAS a (corresponding) body. >...and that > morphed into creating this partial declaration automatically in >response to a limited with clause. This package "abstract," or this >"limited view," is essentially a partial declaration of the package. >Yes, the *package* has a body, but the "limited view" does not have a >body. It is just a bunch of incomplete type declarations. The distinction between "package has..." and "limited view of package has..." is what I find overly language-lawyerly. Anyway, what do you think of Randy's suggested course of action? (I think he wants to change the rule about what can go in a pragma-Pure package, so it simply does not apply to limited views. That seems better than trying to apply the rule to limited views, and then making sure it can't fail because the limited view does not include the body.) If you agree to that, then we can leave the argument (about what "has a body" means) moot. **************************************************************** From: Randy Brukardt Date: Monday, February 7, 2011 12:06 PM ... > I don't see your point, Bob. I hope you all see my point as to why it is best to not try to answer this question. :-) So long as it is clear that the fact that a limited view is considered pure imposes no requirements on the spec or body or any other units, we need not try to decide how many limited views fit on the head of a pin. :-) **************************************************************** From: Bob Duff Date: Monday, February 7, 2011 12:28 PM > So long as it is clear that the fact that a limited view is considered > pure imposes no requirements on the spec or body or any other units, > we need not try to decide how many limited views fit on the head of a > pin. :-) Yes! This is exactly the view (pun!) that I was trying to agree with in my previous email. **************************************************************** From: Edmond Schonberg Date: Monday, February 7, 2011 1:54 PM I'm also perfectly happy with this formulation. **************************************************************** From: Jean-Pierre Rosen Date: Monday, February 7, 2011 2:05 PM > I agree it makes sense to say the limited view omits the body. > Somehow "omits" makes sense to me, where "does not have" > confuses -- the latter (to me) means "does not have a corresponding". I suggested "does not include the body" or "does not cover the body". Does it sound right to you? **************************************************************** From: Erhard Ploedereder Date: Monday, February 7, 2011 3:30 PM > I don't see this at all. We are speaking about a "view" and a limited > view is an extremely narrow window into a package, that allows to you > see a minimum of details. It does not let you see the body, so the > view has no body. Dangerous territory here. In analogy then: "An incomplete type is an extremely narrow view of a type, that allows you to see a minimum of details. It does not let you see the completion, so the view has no completion." Also: "A private view of a type is an extremely narrow view of a type, that allows you to see a minimum of details. It does not let you see the full type, so the private view of a type has no full type." I don't think so. ;-) Is the conceptual difference so large, that one can argue both ways and not be confusing? But, clearly, folks are divided over the issue. It will require careful wording of the "declared pure" stuff, so that both sides can have their cake without choking on it. **************************************************************** From: Bob Duff Date: Monday, February 7, 2011 6:01 PM > > I agree it makes sense to say the limited view omits the body. > > Somehow "omits" makes sense to me, where "does not have" > > confuses -- the latter (to me) means "does not have a corresponding". > > > I suggested "does not include the body" or "does not cover the body". > Does it sound right to you? I am suggesting that we avoid talking about bodies of limited views. Instead, fix the rule that restricts what can appear in a declared-Pure thing -- something like, "This rule does not apply to limited views; @Redundant[those are declared Pure by fiat]". **************************************************************** From: Erhard Ploedereder Date: Monday, February 7, 2011 7:40 PM > I am suggesting that we avoid talking about bodies of limited views. > Instead, fix the rule that restricts what can appear in a > declared-Pure thing -- something like, "This rule does not apply to > limited views; @Redundant[those are declared Pure by fiat]". I agree, and this is where I came from with the rewrite in the AI, until Randy showed me the error of my ways. I'll give it another shot before Tampa. **************************************************************** From: Randy Brukardt Date: Monday, February 7, 2011 8:01 PM Nobody every explained what was wrong with my suggested rewording; it seems that arguing about limited views on the head of a pin is more fun. Here it is again for reference: A pragma Pure is used to declare that a library unit is pure. The declaration and body of a [declared pure] library unit{ to which pragma Pure applies}, 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 {considered} 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 .... This was based on the original Ada 2005 wording (10.2.1(17/2)) talks about rules that apply only when "a pragma Pure" applies to a library unit. The idea is to then allow "declared pure" to mean something slightly different from when a pragma Pure applies. Here we make the pure requirement on the library units in which pragma Pure applies, their bodies and subunits. We then say that the limited view is *also* declared pure. Then the next rule applies to all "declared pure" units. I'm not sure if anything needs to be done to the Preelaborated rules to make this work; I'll think about that if we agree to go this way. **************************************************************** From: Erhard Ploedereder Date: Tuesday, February 8, 2011 7:54 AM Summary, to keep people reading: I am now proposing to change the AI to conclude: "The limited view of a library package is pure if the library package specification is pure." (If sprinkling a couple of "declared" into the sentence, so be it.) Details: Randy wrote: > Nobody every explained what was wrong with my suggested rewording; it > seems that arguing about limited views on the head of a pin is more > fun. Here it is again for reference: > A pragma Pure is used to declare that a library unit is pure. The > declaration and body of a [declared pure] library unit{ to which > pragma Pure applies}, 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 {considered} 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 .... As far as the 2. sentence is concerned, you are technically correct if one makes the mental distinction between "to which pragma pure applies" and "is declared pure". (IMHO, that's just a different pin to dance on, but it would work.) As far as the 4. sentence is concerned, you have one leg over the abyss. It easily escapes the reader that limited views are neither the viewed thing, nor units of any kind in their own right; they seem to be completely outside the rule system of the rest of the world. (I always had the view that views LIMITED the visibility of properties of the real thing, but did not NEGATE (= lie about) these properties.) Besides, I think that the rule might still leave a hole. See below. Frankly, I don't even see the need for the rule " In addition, the limited view of a library package is {considered} declared pure." This rule is relevant only if a dependent unit wants to be declared pure. Three cases arise: a) The real package is declared pure. In that case, if the limited view "inherited" the pureness of the real package, which surely exists and needs to be processed somehow to create the limited view, everything would be fine, as it is with the above rule. b) The real package is not declared pure. In that case, I'd rather know about it now rather than later, since in 99% of all cases, where the body of the importing package with'es the real package, I get my hand slapped anyway by the rules for pureness when the body is compiled. The third (and possibly holey) case is: c) The real package is not pure. In the 1% of all cases, where the body of the importing package does not with the real package, but some non-pure dependent downstream does so, while the above dependent unit already passed on its alleged pureness, my mind boggles to figure out what this means in terms of the intent that pureness be "no actions during elaboration".. I think (with a boggled mind) that the proposed rule may have a hole there (i.e. open more possibilities for acces to unelaborated units). I would much rather have: "The limited view of a library package is considered declared pure if the library package specification is declared pure." The cases: a) is still ok. b) immediate error rather than late error c) immediate error rather than late error (pure dependent downstream) or holes (non-pure dependent downstream) or .... And, it is easy to understand. The whole issue came about as a Pascal question relating to checking pureness rules in generic instantiations. He was asking for a "In addition," boilerplate rule. I really don't see a rationale in AI-35 for the need of a GENERAL pureness of a limited view and the finetuning of very specialized rules that are hard to understand. **************************************************************** From: Edmond Schonberg Date: Tuesday, February 8, 2011 3:01 PM > Summary, to keep people reading: > I am now proposing to change the AI to conclude: > "The limited view of a library package is pure if the library package > specification is pure." (If sprinkling a couple of "declared" into the > sentence, so be it.) Aren't we losing some functionality here? I can imagine a limited_with that denotes some middleware package (possibly implemented in another language) so that the client communicates with it only through callbacks and opaque objects defined elsewhere. That package need not be pure, and nowhere is there a regular with-clause on it. I don't see why this should affect the purity of that client package. > Details: > > > The third (and possibly holey) case is: > c) The real package is not pure. In the 1% of all cases, where the body of the > importing package does not with the real package, but some non-pure > dependent downstream does so, while the above dependent unit already > passed on its alleged pureness, my mind boggles to figure out what > this means in terms of the intent that pureness be "no actions > during elaboration".. > I think (with a boggled mind) that the proposed rule may have a hole > there (i.e. open more possibilities for acces to unelaborated units). Boggles the mind indeed, but my problem is trying to conceive of a scenario where this would a) happen, and b) have undesirable consequences. **************************************************************** From: Randy Brukardt Date: Wednesday, February 9, 2011 11:31 PM I don't see any mind boggling here; moreover we thought about this carefully when we adopted this rule in the first place. Specifically, I don't see how this can happen, because there is no elaboration dependence on a limited view, the elaboration of the limited view has no effect (10.1.1(26.1/2)), and moreover you cannot call a subprogram or access an object via a limited view. So I'm unable to imagine any way to have any significant dependence on a limited view that could cause any elaboration difficulties. Note that the rules in chapter 10 treat a limited view of a unit U like a separate unit from the "regular view" of U. It's not even a "view" in the traditional sense. If those rules didn't do that, we wouldn't even need rules like 10.1.1(26.1/2) [you don't elaborate traditional views at all]. Limited views have their own dependencies (different from the regular view), and they might as well have their own categorization as well. The things that boggles MY mind is that any Ada expert would think that purity has anything to do with "actions at elaboration". There are some requirements in C.4 for that, but they are on a subset of Pure packages. Pure is nothing more and nothing less than a categorization; the only runtime effect is a permission to do certain optimizations. Whether or not there are actions at elaboration is irrelevant. In any case, the original complaint here strikes me as FUD (fear, uncertainty, 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 " 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.] **************************************************************** 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. 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 {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. 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 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. **************************************************************** From: Erhard Ploedereder Date: Tuesday, February 15, 2011 6:23 PM PS. There are couple of places in the RM where "pure" -> "declared pure" should be applied. Using the 05 Manual, the places are A.3(1/2) E.2.2 (18) **************************************************************** From: Randy Brukardt Date: Tuesday, February 15, 2011 7:12 PM > I think that Randy's rewording works. I have small editorials; markups > are relative to Randy's wording. Good to hear. > 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". That is, in the first case, it is a unit that meets the restrictions of pure (or preelaboration), and in the second case, it is a unit that is explicitly declared pure (or considered to have such a declaration in the limited view case). "Pure" is defined by 10.2.1(15.1/2); "declared pure" by this paragraph. It clearly would be better if the terms were more different, but of course "purable" isn't a word. :-) I'm not sure that this distinction is really necessary (it seems to me that specifications [only] can be declared pure, and I don't think they can get to be pure any other way), but I don't want to drop it at this late date without taking the time to think through the implications carefully. The night after a meeting material deadline isn't the timee for that. We can discuss it in St. Pete Beach. [Editor's note: The other changes were made to version /02.] >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". **************************************************************** 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. **************************************************************** From: Tucker Taft Date: Sunday, March 13, 2011 7:46 PM Your suggested changes to resurrect the term "declared pure" seem fine to me. ****************************************************************