!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.)

****************************************************************