!standard 10.2.1(11/3)                              11-02-11    AI05-0243-1/01
!standard 10.2.1(17/3)
!class binding interpretation 11-02-11
!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? (Anything but that.)

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

[Editor's notes: A nice side-effect of this rewording is that we can
italize the defined term "declared pure", which was not possible with the old
wording.

I would rather talk about the presence or absence of the aspect Pure, but the
proposed wording for "Boolean pragmas" (of which this is one) talks about
setting the value to True. These need to be consistent.]


Replace 10.2.1(11/3) [as modified by AI05-0034-1]:

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 is set to
True (or the Pure aspect @emdash see below) for 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 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.

[Editor's note: We need to mention "declared pure" here so that we include
limited views; these do not have the Pure 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, 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.]

[Question:
  It weird that we can write:
    package P is
       pragma Pure (P);
       pragma Preelaborate (P);

    (at least as far as I can tell, I can find no rule banning it);
    it's weirder to be able to write:
    package P
       with Pure, Preelaborate is

    But there does not appear to be a semantic problem with this, so I didn't
    make any attempt to ban either form. Should we? Note that we do need
    multiple categorizations in some cases, so a general rule wouldn't work
    well - unless we defined a Preelaborated/Remote_Types combo categorization.
    That's probably too much change. So any added rule would be specific to
    Pure/Preelaborate.]

Replace E.2(2):

A *categorization aspect* is a representation aspect (see 13.1) that restricts the
declarations, child units, or semantic dependences of the library unit to which it
applies. A *categorization pragma* is a library unit pragma (see 10.1.5) that sets
a categorization aspect. A categorized library unit is a library unit to which a
categorization aspect applies.

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):

A library package or generic library package is called a shared passive library unit if
the Shared_Passive aspect of the unit has the value True. A library package or generic
library package is called a remote types library unit if the Remote_Types aspect of
the unit has the value True. A library unit package or generic library package is called
a remote call interface if the Remote_Call_Interface aspect has the value True.
A normal library unit is one for which no categorization aspect has the value True. 

Replace E.2.1(4):

A pragma Shared_Passive sets the Shared_Passive 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 Shared_Passive
aspect on a library unit to True specifies that the unit is a *shared passive
library unit*. The following restrictions apply to such a library unit:

Replace E.2.2(4):

A pragma Remote_Types sets the Remote_Types 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 Remote_Types
aspect on a library unit to True specifies that the unit is a *remote types
library unit*. The following restrictions apply to such a library unit:

Replace E.2.3(7/1):

A pragma Remote_Call_Interface sets the Remote_Types 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 Remote_Types
aspect on a library unit to True specifies that the unit is a *remote types
library unit*. The following restrictions apply to such a library unit:

Replace "pragma" with "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.

We define these as a representation aspects so as to take advantage of 13.1(9)
(which prevents specifying it more than once). (Operational aspects only have
that rule for types.) This is also why we define the pragma to set the aspect:
this prevents giving both the pragma and the aspect.

---

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<pragma> Preelaborate (or @fa<pragma> 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 @fa<library_item>s of the partition.
@dby
A @fa<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 @fa<aspect_specification> of the @fa<library_item>. If the Preelaborate
aspect is set to True (or the Pure aspect @emdash see below) for a library unit,
then it is @i<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 @fa<library_item>s of the partition.

!corrigendum 10.2.1(17/3)

@drepl
A @fa<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).
@dby
A @fa<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
@fa<aspect_specification> of the @fa<library_item>. Setting the Pure aspect on a
library unit to True specifies that the unit is @i<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 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.]

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