!standard 13.1.1(4/3) 15-02-20 AI05-0154-1/00 !class binding interpretation 15-02-20 !status work item 15-02-20 !status received 15-02-18 !priority Low !difficulty Easy !qualifier Omission !subject Aspects of library units !summary ** TBD. !question ** TBD. !recommendation (See Summary.) !wording ** TBD. !discussion ** TBD. !corrigendum 5.5.2(5/3) @drepl @dby !ASIS No ASIS effect. !ACATS test ** TBD. !appendix From: Randy Brukardt Sent: Wednesday, February 18, 2015 3:46 PM The first sentence 13.14(3/4) determines when the contents of a library package are frozen. But I don't see anything anywhere that says when the library package itself is frozen. Taken literally, that would imply that it is frozen at the end of Standard, but do you ever reach the end of Standard (given that you can add [compile] additional units at any time])? I care because 13.1.1(37/3) and 13.14(7.2/3) say that expressions in an aspect specification are evaluated no sooner than the first freezing point (and are resolved based on the end of the enclosing declaration list [13.1.1(11/3)], something that never happens for a library unit). Thus, I wonder when the aspect for a categorization pragma is resolved and evaluated. In particular, is the following legal? package P with Pure => Purity is -- Var : Integer; Purity : constant Boolean := True; end P; The above seems to violate the Dewar rule, given that we weren't trying to add any capabilities with these aspect and pragma Pure takes effect immediately. Note that if this is legal there would need to be some sort of retroactive check for purity of the preceding declarations (imagine that Var was uncommented). That seems like a lot of work for virtually no benefit. (There is a similar question about where pragma Convention is allowed for P, but as that's not required of any implementation, it's the sort of question not worth asking.) Did we intend P to be frozen immediately upon declaration? Or did we intend a special rule (that doesn't exist) for the categorization aspects? Or did we really intend the above example to work? **************************************************************** From: Edmond Schonberg Sent: Wednesday, February 18, 2015 4:00 PM That example must be illegal. The aspect should be equivalent to a pragma appearing after the declaration of the package, but then environment-level visibility rules prevent the pragma from mentioning anything declared within the package. **************************************************************** From: Tucker Taft Sent: Wednesday, February 18, 2015 4:04 PM > The first sentence 13.14(3/4) determines when the contents of a > library package are frozen. But I don't see anything anywhere that > says when the library package itself is frozen. Taken literally, that > would imply that it is frozen at the end of Standard, but do you ever > reach the end of Standard (given that you can add [compile] additional units > at any time])? Interesting point. I would say that the end of a compilation unit freezes any contained library unit declaration. I say compilation unit instead of library unit so that it includes any trailing pragmas. > I care because 13.1.1(37/3) and 13.14(7.2/3) say that expressions in an > aspect specification are evaluated no sooner than the first freezing point > (and are resolved based on the end of the enclosing declaration list > [13.1.1(11/3)], something that never happens for a library unit). > > Thus, I wonder when the aspect for a categorization pragma is resolved and > evaluated. In particular, is the following legal? > > package P with Pure => Purity is > -- Var : Integer; > Purity : constant Boolean := True; > end P; We need to specify what is visible in such an aspect clause, and whether it is inside or outside the declarative region associated with P. The above is admittedly weird, but less weird would be specifying, say, a procedure of a package that is supposed to be called when the package is about to be finalized. E.g. package P with Finalize => Cleanup is ... procedure Cleanup; end P; or a boolean expression that represents a package invariant: package P with Package_Invariant => All_Is_Copacetic is ... function All_Is_Copacetic return Boolean; end P; > ... Did we intend P to be frozen immediately upon declaration? Or did we > intend a special rule (that doesn't exist) for the categorization aspects? Or > did we really intend the above example to work? I would say that the name resolution should be deferred for these as well, so that you can specify things like package invariants. In general, one would hope that library packages and nested packages have nearly the same functionality w.r.t. aspects. **************************************************************** From: Tucker Taft Sent: Wednesday, February 18, 2015 4:05 PM > That example must be illegal. The aspect should be equivalent to a > pragma appearing after the declaration of the package, but then > environment-level visibility rules prevent the pragma from mentioning anything > declared within the package. Not sure I agree. Presumably aspects on library subprograms at least "see" the parameters, so perhaps package aspects should "see" their visible components. I already sent a longer response. **************************************************************** From: Edmond Schonberg Sent: Wednesday, February 18, 2015 4:21 PM In general aspects can be specified equivalently with aspect specifications and with pragmas. I imagine we want to preserve that equivalence as much as possible. so for aspect specifications that apply to compilation units we need a rule that says whether the equivalent pragma appears at the end of the specification, or as a compilation unit pragma. Visibility rules for pre- and post-conditions are already special, I'm not sure I see the equivalence between formals of subprograms and local entities in a package. **************************************************************** From: Tucker Taft Sent: Wednesday, February 18, 2015 4:42 PM > In general aspects can be specified equivalently with aspect > specifications and with pragmas. I imagine we want to preserve that > equivalence as much as possible. so for aspect specifications that > apply to compilation units we need a rule that says whether the > equivalent pragma appears at the end of the specification, or as a compilation > unit pragma. Well for the pragmas that became aspects in Ada 2012, the pragmas had generally been pragmas that occurred at the beginning of the specification, such as pragma Pure, which are usually "library unit pragmas" or "program unit pragmas." > ... Visibility > rules for pre- and post-conditions are already special, I'm not sure I > see the equivalence between formals of subprograms and local entities > in a package. Well, I saw them as related because both are declared "inside" the declarative region of the entity associated with the aspect. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 18, 2015 4:50 PM >In general aspects can be specified equivalently with aspect specifications >and with pragmas. I imagine we want to preserve that equivalence as much as >possible. so for aspect specifications that apply to compilation units we need >a rule that says whether the equivalent pragma appears at the end of the >specification, or as a compilation unit pragma. Visibility rules for >pre- and post-conditions are already special, I'm not sure I see the >equivalence between formals of subprograms and local entities in a package. I find Ed's logic backwards, but I agree with his conclusion. In particular, I'd expect that aspects that correspond to library unit pragmas (which have to appear first inside of a library package), have to be resolved and evaluated immediately. It doesn't make sense to delay their effect in any way, as that would require retroactive action compared to the pragmas, and we surely didn't intend to make that much work for implementers (given that it isn't useful in any way that I can think of). OTOH, other aspects might want different rules. Perhaps saying that it happens at the end would make sense for them. Thus, it seems to me that we need a rule that overrides whatever the rules are for other aspects for library unit pragmas. (We already have part of that (13.1.1(32/3)) for such pragmas. I'd simply add another rule that library unit pragmas "nothwithstanding other rules" are resolved and evaluated immediately. Presuming that's what we want. (Ed and I are in agreement on this point, not sure about the rest.) Note that there still is the possibility of using an object from outside of the package: package Consts is Purity : constant Boolean := True; end Consts; with Consts; package P with Pure => Consts.Purity is ... end P; I believe that P is legal here and we intended that to be the case. (That does mean that the aspects have slightly more capability than the pragmas, but I don't think that capability is particularly useful. Perhaps in conjuction with debugging, turning off purity in a bunch of units at once would be helpful? Dunno.) ****************************************************************