!standard 10.2.1(11/1) 07-06-17 AI05-0034-1/02 !standard 10.2.1(17/2) !class binding interpretation 07-01-12 !status work item 07-01-12 !status received 07-01-11 !priority Medium !difficulty Easy !qualifier Omission !subject Categorization of limited views !summary A limited view is considered pure, no matter what the categorization of the unit that gave rise to the view. !question Consider: package Lim is pragma Preelaborate (Lim); type Something is ...; end Lim; limited with Lim; -- OK? package Dep is pragma Preelaborate (Dep); ... end Dep; Preelaborated units can only have a semantic dependence on units that are preelaborated. A limited with creates a semantic dependence on a limited view. But is a limited view preelaborated? 10.1.1(11.1-3/2) does not include the pragma in the contents of the view, so it appears the answer is no. But a regular with clause would be legal here, so this is inconsistent. What is intended here? !recommendation (See summary.) !wording Add after the first sentence of 10.2.1(11/1): In addition, the limited view of a library package is preelaborated. Add after the first sentence of 10.2.1(17/2): In addition, the limited view of a library package is declared pure. [Editor's note: This has a bad interaction with the wording changes of AI05-0035-1.] !discussion One possible interpretation would be to consider the limited view to be one of the compilation units of the library unit that does contain the pragma. Then, the dependence would be legal by the wording of 10.2.1(11/1). "...shall depend semantically only on compilation units of other preelaborated library units." But limited views have no impact on elaboration: the elaboration of a limited view of a package has no effect. So it's bizarre to worry about the categorization of a limited view for the purposes of elaboration. Hence, limited views should be removed from consideration, effectively treating them all as declared Pure. Note that this does allow some unusual dependence on non-preelaborated units, for which the full view cannot be used (because the semantic dependence on the unit would not be allowed). But this could actually be useful to provide more functionality to the notoriously limited preelaborated units. package Lim2 is -- Not preelaborated. type Something is ...; end Lim2; limited with Lim2; -- OK package Dep2 is pragma Preelaborate (Dep2); ... end Dep2; with Lim2; -- Illegal. package body Dep2 is ... end Dep2; There is no problem with this extension and Annex E. If a limited with is used to reference a regular unit into a passive partition, the partition would have to include that regular unit (by the "needs" rules in 10.2). But a passive partition that includes a regular unit is illegal by E.1(3). Thus this expansion allows no new functionality in a passive partition. --!corrigendum A.18.2(239/2) !ACATS test !appendix From: Randy Brukardt Date: Thursday, January 11, 2001 10:38 PM I'm trying to figure out whether we need new tests for limited with in the case of preelaborated units. And I'm confused. Consider: package Lim is pragma Preelaborate (Lim); type Something is ...; end Lim; limited with Lim; -- OK? package Dep is pragma Preelaborate (Dep); ... end Dep; Is package Dep legal? 10.2.1(11/1) says that Dep can only have a semantic dependence on "compilation units of other preelaborated library units". A preelaborated library unit is one to which pragma Preelaborate or Pure applies (10.2.1(11)). A limited with creates a semantic dependence on a limited view. A limited view does not contain a pragma Preelaborate, because it's not in the contents listed by 10.1.1(12.1-3/2). So it is not preelaborated that way. So I was originally convinced that the limited view is not preelaborated and thus Dep should be rejected. (Which would be a problem.) However, the language of 10.2.1(11/1) is weird. What are the "compilation units of other preelaborated library units"? There's no note to help, and definition of "compilation unit" refers only to the syntax item compilation_unit (which of course defines no relationship between units). 10.1.1(12.5/2) does say that a limited view is an implicit compilation unit. So I suppose we can take an expansive view of what "compilation units of a library unit" mean and include everything (bodies, subunits, limited views, the kitchen sink ;-) In that case, the program is legal. I guess I'm still concerned, because generally limited views are in a parallel universe that don't interact with the real universe except at certain well-defined points (which have explicit language). This seems to need to be such a point, but there is no indication anywhere that anyone considered this case. (Indeed, one could argue that all limited views should be treated as Pure, since they don't have an elaboration dependence, and nothing that causes trouble - like allocators - can be done with them. I'm not sure that it's worth going that far.) We at least need an AARM note to mention that limited views are included here (10.2.1(11/1) and 10.2.1(17/2)). What do you think?? **************************************************************** From: Tucker Taft Date: Thursday, January 11, 2007 10:51 PM The elaboration of a limited view of a package has no effect. Hence, I would suggest we remove them from consideration, effectively treating them all as declared Pure. And I agree this was an oversight, and will require a Binding Interpretation to make it official. **************************************************************** From: Randy Brukardt Date: Thursday, January 11, 2007 11:21 PM That's OK with me (other than it means we can't test this area now). We need to be careful that such a rule doesn't provide a back door to get non-passive junk into a passive partition. But E.1(3) makes such a partition illegal, so I think we're OK. **************************************************************** From: Pascal Leroy Date: Friday, January 12, 2007 1:27 AM > The elaboration of a limited view of a package has no effect. > Hence, I would suggest we remove them from consideration, > effectively treating them all as declared Pure. And I agree > this was an oversight, and will require a Binding > Interpretation to make it official. I agree with Tuck. ****************************************************************