Version 1.5 of ai05s/ai05-0243-1.txt
!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)
Replace the paragraph:
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 non-preelaborated library_items of the partition.
by:
A pragma 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 aspect_specification of the library_item. If the Preelaborate
aspect (or the Pure aspect — see below) is set to True for a library unit,
then 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, are elaborated prior to all
non-preelaborated library_items of the partition.
!corrigendum 10.2.1(17/3)
Replace the paragraph:
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 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).
by:
A pragma 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
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 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 <some library unit>" 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.
****************************************************************
Questions? Ask the ACAA Technical Agent