Elaboration of nested generic package.

Elaboration of nested generic package.

[Don Westermeyer]

Hello,

I'm hoping someone can answer my question.  I would like to know if
using the pragma 'elaborate_body' in a package also also performs
guarantees the elaboration of nested generic packages.

Thanks a lot!


Example:

package Example_Bad is

  -- This is ok.
  pragma elaborate_Body;

  procedure Do_Something;


  


  generic
     type Item_Type is private;
 
  package Nested_package is
    
    -- This is the problem because it this is a nested package.  
    -- The intent is to elaborate instantiations like if this 
    -- was in its own package.
    -- FWIW - This compiles with Rational Ada but not Aonix 
    -- which references LRM:10.1.5(2).  
    -- I would like to get rid of this but don't know if it
    -- is 'safe'. See:
    -- http://www.adaic.org/docs/95style/html/sec_8/8-4-3.html

    pragma Elaborate_Body;
  


    procedure Do_Another_Thing;


  end Nested_Package;



end Example_Bad;

Re: Elaboration of nested generic package.

[christoph.grein]

package Example is

  pragma Elaborate_Body;

  procedure Do_Something;

  generic
    type Item_Type is private;
  package Nested is
    --pragma Elaborate_Body;
    procedure Do_Another_Thing;
  end Nested;

end Example;

There is no need to put pragma Elaborate_Body into the nested generic, because 
the body of Example also holds the body of Nested, and when the body of Example 
is elaborated, the body of Nested is inevitably elaborated as well.

What you cite in the style guide applies only to library generic units (or 
should that be generic library units :-):
http://www.adaic.org/docs/95style/html/sec_8/8-4-3.html

Re: Elaboration of nested generic package.

[Don Westermeyer]

christoph.grein@eurocopter.com wrote in message news:<mailman.0.1057119854.328.comp.lang.ada@ada.eu.org>...
> package Example is
> 
>   pragma Elaborate_Body;
> 
>   procedure Do_Something;
> 
>   generic
>     type Item_Type is private;
>   package Nested is
>     --pragma Elaborate_Body;
>     procedure Do_Another_Thing;
>   end Nested;
> 
> end Example;
> 
> There is no need to put pragma Elaborate_Body into the nested generic, because 
> the body of Example also holds the body of Nested, and when the body of Example 
> is elaborated, the body of Nested is inevitably elaborated as well.
> 
> What you cite in the style guide applies only to library generic units (or 
> should that be generic library units :-):
> http://www.adaic.org/docs/95style/html/sec_8/8-4-3.html


Thanks for the reply.  I was hoping that was the case.  It's hard to
interpret the LRM somtimes.  IMO Ada 83/95 could have made the whole
issue of elaboration easier to deal with (for instance always
elaborate the body UNLESS a pragma 'Do_Not_Elaborate' is applied).

Thanks again.
D Westermeyer.

Re: Elaboration of nested generic package.

[Matthew Heaney]

dlwester@hotmail.com (Don Westermeyer) wrote in message news:<5437fafb.0307071905.5d3bbc4e@posting.google.com>...
> christoph.grein@eurocopter.com wrote in message news:<mailman.0.1057119854.328.comp.lang.ada@ada.eu.org>...
> > 
> > There is no need to put pragma Elaborate_Body into the nested generic, because 
> > the body of Example also holds the body of Nested, and when the body of Example 
> > is elaborated, the body of Nested is inevitably elaborated as well.
> > 
> > What you cite in the style guide applies only to library generic units (or 
> > should that be generic library units :-):
> > http://www.adaic.org/docs/95style/html/sec_8/8-4-3.html

I don't think it matters much what the generic itself says.  Whenever
you instantiate a generic package, you should always Elaborate_All on
the with clause:

with GP;
pragma Elaborate_All (GP);  --you need this

package body Q is
   package P is new GP;
end Q;

See the CLA thread "AQ&S Guidance on pragma Elaborate_Body" which
occurred in 1997/04 -- particularly the responses from Bob Duff and
Robert Dewar.

I forget whether you need the pragma for root-level instantiations:

with GP;
pragma Elaborate_All (GP); --needed?
package P is new GP;

I don't think the pragma inside the generic declaration does very
much, except to indicate to the reader about whether the package uses
named access types, etc.  It's the Elaborate_All pragma that's
important for generics.

Perhaps Bob Duff can, er, elaborate.

-Matt

Re: Elaboration of nested generic package.

[christoph.grein]

Matthew,

I do not see why you think there is a difference whether you instantiate on 
library level or on a nested level:

> with GP;
> pragma Elaborate_All (GP);  --you need this
>
> package body Q is
>    package P is new GP;
> end Q;
>
> See the CLA thread "AQ&S Guidance on pragma Elaborate_Body" which
> occurred in 1997/04 -- particularly the responses from Bob Duff and
> Robert Dewar.
>
> I forget whether you need the pragma for root-level instantiations:
>
> with GP;
> pragma Elaborate_All (GP); --needed?
> package P is new GP;

The pragma says: Elaborate all units that are on the with-tree of the with-ed 
unit (GP) before elaborating the with-ing package (Q resp. P). And the body of 
the generic is needed elaborated before instantiation in any case.

Whether the pragma in the generic spec is of any use, I do not know either and I 
presently do not feel like searching the RM :-(

Re: Elaboration of nested generic package.

[Don Westermeyer]

> 
> I don't think it matters much what the generic itself says.  Whenever
> you instantiate a generic package, you should always Elaborate_All on
> the with clause:
> 
> with GP;
> pragma Elaborate_All (GP);  --you need this
> 
> package body Q is
>    package P is new GP;
> end Q;
> 
> See the CLA thread "AQ&S Guidance on pragma Elaborate_Body" which
> occurred in 1997/04 -- particularly the responses from Bob Duff and
> Robert Dewar.
> 
> I forget whether you need the pragma for root-level instantiations:
> 
> with GP;
> pragma Elaborate_All (GP); --needed?
> package P is new GP;
> 
> I don't think the pragma inside the generic declaration does very
> much, except to indicate to the reader about whether the package uses
> named access types, etc.  It's the Elaborate_All pragma that's
> important for generics.
> 
> Perhaps Bob Duff can, er, elaborate.
> 
> -Matt
You should not need an Elaborate_All pragma if the specification
contains pragma Elaborate_Body since the body is elaborated
immediately after the specification.

Using Elaborate_All certainly works also, but a lot of people either
forget or more often just don't bother using it.  It seems to me using
pragmas Pure, Preelaborate, and Elaborate_Body should make usage of a
package more fool-proof.  When used, they also then to enforce that
designers and programmers develop software using non-circular,
'top-down' designs.

It seems to me that the Ada language should have assumed an
'Elaborate_All' for every dependancy unless a pragma was used to
specifically ignore it.  It would seem the compilers should also know
when it can ignore elaboration checking without the user specifying
Pure or Preelaborate.

I'd say most of the people maintaining large Ada projects do not even
know the issues of elaboration and how to deal with them. (And it's
not like there's a lot of money for training these days.)


Usually I do use pragma Elaborate_All for every dependancy anyway
since one does not have control over every software module developed. 
Using it is always safer and causes no penalties that I know of
(assuming the design stays clear of mutual dependancies).

Re: Elaboration of nested generic package.

[Robert I. Eachus]

Don Westermeyer wrote:

> Usually I do use pragma Elaborate_All for every dependancy anyway
> since one does not have control over every software module developed. 
> Using it is always safer and causes no penalties that I know of
> (assuming the design stays clear of mutual dependancies).

This is silly.  The reason that Ada doesn't automagically assume 
Elaborate_Body or Elaborate_All, is that there is a better assumption. 
The implementation knows the potential elaboration issues and is 
encouraged to chose one that cannot result in Program_Error.

So why then do the pragmas exist?  Because it is possible to write 
programs with several different legal elaboration orders, and it may be 
either impossible (you can imbed an instance of the Halting Problem) for 
the compiler to choose the intended elaboration order, or the "correct" 
elaboration order can depend on something read in at execution time.  In 
either of those two cases, the compiler can tell the programmer, "If 
you're so smart, you tell me how to do it."

But in general, if the compiler can't figure it out, the programmer is 
very unlikely to have a decent answer in mind.

Using pragma Elaborate, Elaborate_All, or Elaborate_Body 
indiscriminantly can only make the Ada compiler's job harder.  There are 
two exceptions though.  If you know that the subprograms declared in a 
package are used before the main program is elaborated, by all means use 
Elaborate_All.  Also, if you have a package that would not otherwise 
require a body, pragma Elaborate_Body can insure that a body is 
required.  Otherwise you can get embarrassed if the body is not updated 
when the specification is changed.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Elaboration of nested generic package.

[Robert I. Eachus]

Robert I. Eachus wrote:

>               Also, if you have a package that would not otherwise 
> require a body, pragma Elaborate_Body can insure that a body is 
> required.  Otherwise you can get embarrassed if the body is not updated 
> when the specification is changed.

Oops! Silly me! We fixed that one, the pragma is now necessary if you 
intend to provide a body, if the body is not otherwise required.  (Why 
would you want to do that?  I don't know.  But there is a way to do it 
if necessary.)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Elaboration of nested generic package.

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


"Robert I. Eachus" <rieachus@attbi.com> a �crit dans le message de news:3F0CF0AE.5030409@attbi.com...
> Oops! Silly me! We fixed that one, the pragma is now necessary if you
> intend to provide a body, if the body is not otherwise required.  (Why
> would you want to do that?  I don't know.  But there is a way to do it
> if necessary.)

A package that declares only tasks in the body comes to mind....

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Elaboration of nested generic package.

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F0CC2D1.10904@attbi.com>...
> Don Westermeyer wrote:
> 
> > Usually I do use pragma Elaborate_All for every dependancy anyway
> > since one does not have control over every software module developed. 
> > Using it is always safer and causes no penalties that I know of
> > (assuming the design stays clear of mutual dependancies).
> 
> This is silly.  The reason that Ada doesn't automagically assume 
> Elaborate_Body or Elaborate_All, is that there is a better assumption. 
> The implementation knows the potential elaboration issues and is 
> encouraged to chose one that cannot result in Program_Error.

I was talking about library-level instantiations of generic packages.

Back in 1997, Bob Duff and Robert Dewar seemed to suggest that you
always need Elaborate_All on the generic package:

with GP;
pragma Elaborate_All (GP); --Do you need this pragma...
package P is new GP;       --...in order to instantiate?

If we're not talking about with'ing a generic package, then I agree
that it is silly to use the Elaborate_All on every dependency.  It
only makes it harder for the compiler to find an acceptable
elaboration order, because you have constrained the size of the set of
possible orders.

You should only use it when the dependent unit calls subprograms
provided by the with'd unit during its own elaboration.


> Using pragma Elaborate, Elaborate_All, or Elaborate_Body 
> indiscriminantly can only make the Ada compiler's job harder.  There are 
> two exceptions though.  If you know that the subprograms declared in a 
> package are used before the main program is elaborated, by all means use 
> Elaborate_All.  

Yes.

I would still like a definitive answer, though.  In order to make a
library-level package instantiation, do I need to use Elaborate_All on
the generic unit? (As in the example above.)

Also: do the categorization pragmas in a generic unit make any
difference?  In other words, you still need to say Elaborate_All,
irrespective of what the generic unit says about categorization --
correct?

Re: Elaboration of nested generic package.

[Don Westermeyer]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F0CC2D1.10904@attbi.com>...
> 
>>
> But in general, if the compiler can't figure it out, the programmer is 
> very unlikely to have a decent answer in mind.
>

Well, some compilers do better at this than others, and in the case of
one compiler I've worked it apparently just picks a fairly random
order in which to elaborate things.  The elaborate pragmas pretty much
guarantee elaboration dependancy problems are caught at compile/link
time vs. execution (where on target hardware the debugging can be
quite difficult - especially exceptions during elaboration).

Another problem is when using packages written by others you may not
know if it needs to be elaborated or not.  For instance by just simply
declaring a variable one can set off a complex series of program
statements.

Seems to me that it is always safer to use the pragmas.  As long as
circular dependancies are avoided the compile will have no difficulty
with this.


At least Ada provides decent error checking for elaboration issues. 
Other languages (like Borland Delphi for instance) will just let you
hang yourself if you get too fancy during elaboration.

Re: Elaboration of nested generic package.

[Robert I. Eachus]

Jean-Pierre Rosen wrote:

> A package that declares only tasks in the body comes to mind....

Could happen.  But the few times I have done something like that, there 
is a task type, and objects of that type.  I guess it would have been 
possible to declare the task type in the body also, but making the task 
type visible, even when not strictly necessary, seems more natural.

Doesn't matter.  The ability is there if needed, and in Ada 95 the 
potential gotcha from Ada 83 is gone.
-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Elaboration of nested generic package.

[Robert I. Eachus]

Matthew Heaney wrote:

> I would still like a definitive answer, though.  In order to make a
> library-level package instantiation, do I need to use Elaborate_All on
> the generic unit? (As in the example above.)

Hmmm.  A marginal case, but I would go ahead and do it.  You are using 
the generic declaration before the main program starts, but may or may 
not need Elaborate_All instead of Elaborate.  Use of Elaborate is 
deprecated.  There are cases where Elaborate will work but Elaborate_All 
can't.  However, it is unlikely that you will run into one.

> Also: do the categorization pragmas in a generic unit make any
> difference?  In other words, you still need to say Elaborate_All,
> irrespective of what the generic unit says about categorization --
> correct?

Technically, the right answer is that you don't need Elaborate or 
Elaborate_All for packages without bodies.  This is very different from 
what the categorization pragmas do.

Most compilers today try to elaborate the body immediately after the 
package specification whenever possible.  So all these discussions of 
pragma Elaborate_All really deal with the cases where that is not 
possible.  Let me give an example:

package Foo is...end Foo;

with Foo;
package Bar is...end Bar;

with Bar;
package body Foo is...end Foo;

package body Bar is...end Bar;

Once you have this sort of loop, elaboration can become an issue.  In 
this case there is nothing in the language rules that determines whether 
the body of Foo will be elaborated before the body of Bar (or 
vice-versa) absent pragmas.  Most of the time it won't matter.  But if 
you know that elaboration of the body of Foo will call a subprogram in 
Bar, you should provide the pragma.  Or elaboration of the body of Bar 
could call a subprogram in Foo.  If both occur, or could occur, that is 
when you have elaboration problems.
-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Elaboration of nested generic package.

[Matthew Heaney]

dlwester@hotmail.com (Don Westermeyer) wrote in message news:<5437fafb.0307091710.5cb4b0eb@posting.google.com>...
> > 
> You should not need an Elaborate_All pragma if the specification
> contains pragma Elaborate_Body since the body is elaborated
> immediately after the specification.

But we're talking about a generic unit.  I think that whenever you
instantiate a generic at library level, you need to use the
Elaborate_All pragma.

The categorization pragma inside the generic doesn't matter, because
that only applies to the instantiation (I think...), which doesn't
exist yet.


> It seems to me that the Ada language should have assumed an
> 'Elaborate_All' for every dependancy unless a pragma was used to
> specifically ignore it.  It would seem the compilers should also know
> when it can ignore elaboration checking without the user specifying
> Pure or Preelaborate.

No.  This would unnecessarily constrain the size of the set of all
possible elaboration orders.

 
> Usually I do use pragma Elaborate_All for every dependancy anyway
> since one does not have control over every software module developed. 
> Using it is always safer and causes no penalties that I know of
> (assuming the design stays clear of mutual dependancies).

This is a very bad idea.

Re: Elaboration of nested generic package.

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> "Robert I. Eachus" <rieachus@attbi.com> a �crit dans le message de news:3F0CF0AE.5030409@attbi.com...
> > Oops! Silly me! We fixed that one, the pragma is now necessary if you
> > intend to provide a body, if the body is not otherwise required.  (Why
> > would you want to do that?  I don't know.  But there is a way to do it
> > if necessary.)
> 
> A package that declares only tasks in the body comes to mind....

Yes.  Also, another case comes to mind: you want to declare a type
extension in a package body, where the package spec is totally empty.
The Initialize operation might register objects of the type into some
global data structure.  Nobody calls the operations of this type
directly, but only via dispatching.

- Bob

Re: Elaboration of nested generic package.

[Robert A Duff]

mheaney@on2.com (Matthew Heaney) writes:

> "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3F0CC2D1.10904@attbi.com>...
> > Don Westermeyer wrote:
> > 
> > > Usually I do use pragma Elaborate_All for every dependancy anyway
> > > since one does not have control over every software module developed. 
> > > Using it is always safer and causes no penalties that I know of
> > > (assuming the design stays clear of mutual dependancies).
> > 
> > This is silly.  The reason that Ada doesn't automagically assume 
> > Elaborate_Body or Elaborate_All, is that there is a better assumption. 
> > The implementation knows the potential elaboration issues and is 
> > encouraged to chose one that cannot result in Program_Error.
> 
> I was talking about library-level instantiations of generic packages.
> 
> Back in 1997, Bob Duff and Robert Dewar seemed to suggest that you
> always need Elaborate_All on the generic package:
> 
> with GP;
> pragma Elaborate_All (GP); --Do you need this pragma...
> package P is new GP;       --...in order to instantiate?
> 
> If we're not talking about with'ing a generic package, then I agree
> that it is silly to use the Elaborate_All on every dependency.  It
> only makes it harder for the compiler to find an acceptable
> elaboration order, because you have constrained the size of the set of
> possible orders.
> 
> You should only use it when the dependent unit calls subprograms
> provided by the with'd unit during its own elaboration.
> 
> 
> > Using pragma Elaborate, Elaborate_All, or Elaborate_Body 
> > indiscriminantly can only make the Ada compiler's job harder.  There are 
> > two exceptions though.  If you know that the subprograms declared in a 
> > package are used before the main program is elaborated, by all means use 
> > Elaborate_All.  
> 
> Yes.
> 
> I would still like a definitive answer, though.  In order to make a
> library-level package instantiation, do I need to use Elaborate_All on
> the generic unit? (As in the example above.)

If the generic unit says Elaborate_Body, then you do not.  However,
Elab_Body causes a problem: the body can't "with" its own children,
which is often useful.

If you don't have Elab_Body, and you say "with Some_Generic", then you
should normally Elab_All of the generic, because your instances will
normally be at library level.  If your instances are nested in
procedures, then you don't normally need to do that.  There are some
rare cases where Elab_All won't work, and you have to use pragma
Elaborate instead.

This part of the language is something of a mess.  Pragma Elaborate was
added late in the game of Ada 83, and it was later realized that it
doesn't work well, and we tried to fix it in Ada 95, and pretty much
failed.  We added some pragmas, but as evidenced by this thread, it's
not always clear when to use them.

But if you use GNAT in its default mode, it will tell you where you need
the pragmas, mostly.  It doesn't work in the case of
indirect/dispatching calls, though.

> Also: do the categorization pragmas in a generic unit make any
> difference?  In other words, you still need to say Elaborate_All,
> irrespective of what the generic unit says about categorization --
> correct?

I think there is an AI on this point.  Sorry, I don't remember the
details.

- Bob

Re: Elaboration of nested generic package.

[Matthew Heaney]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc65m8pwq1.fsf@shell01.TheWorld.com>...
> mheaney@on2.com (Matthew Heaney) writes:
> 
> > I would still like a definitive answer, though.  In order to make a
> > library-level package instantiation, do I need to use Elaborate_All on
> > the generic unit? (As in the example above.)
> 
> If the generic unit says Elaborate_Body, then you do not.  However,
> Elab_Body causes a problem: the body can't "with" its own children,
> which is often useful.
> 
> If you don't have Elab_Body, and you say "with Some_Generic", then you
> should normally Elab_All of the generic, because your instances will
> normally be at library level.  If your instances are nested in
> procedures, then you don't normally need to do that.  There are some
> rare cases where Elab_All won't work, and you have to use pragma
> Elaborate instead.
> 
> This part of the language is something of a mess.  Pragma Elaborate was
> added late in the game of Ada 83, and it was later realized that it
> doesn't work well, and we tried to fix it in Ada 95, and pretty much
> failed.  We added some pragmas, but as evidenced by this thread, it's
> not always clear when to use them.
> 
> But if you use GNAT in its default mode, it will tell you where you need
> the pragmas, mostly.  It doesn't work in the case of
> indirect/dispatching calls, though.
> 
> > Also: do the categorization pragmas in a generic unit make any
> > difference?  In other words, you still need to say Elaborate_All,
> > irrespective of what the generic unit says about categorization --
> > correct?
> 
> I think there is an AI on this point.  Sorry, I don't remember the
> details.

Things are even more weird, at least wrt GNAT.

I have this:

generic 
   ...
package GP is
   pragma Preelaborate;
   ...
end GP;

And then I instantiate it, like this:

with GP;
pragma Elaborate_All (GP);
package P is new GP (...);

I then with it from a normal packet that has a categorization pragma:

with P;
package Q is
   pragma Preelaborate;
   ...
end Q;

What's weird is that the compiler is telling me I'm not allowed to
with P from a preelaborate package Q.  I was surprised by this
behavior, because GP says explicitly that it is Preelaborate
categorization.

To make the compiler happy I have to use a confirming pragma on the
instantion of GP:

with GP;
pragma Elaborate_All (GP);
package P is new GP (...);
pragma Preelaborate (P);

and then Q compiles without error.

Is this normal behavior?  This is the reason I was asking whether the
categorization pragmas do anything if they're declared in a generic
package.

Is it necessary to use a categorization pragma on library-level
package instantiations?

-Matt

Re: Elaboration of nested generic package.

[Randy Brukardt]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1ec946d1.0307141035.3f1e4b80@posting.google.com...
> Is this normal behavior?  This is the reason I was asking whether the
> categorization pragmas do anything if they're declared in a generic
> package.
>
> Is it necessary to use a categorization pragma on library-level
> package instantiations?

GNAT is correct. The corrigendum says in 10.1.5(7.1/1):

A library unit pragma that applies to a generic unit does not apply to its
instances, unless a specific rule for the pragma specifies the contrary.

That means that a categorization pragma does not apply to instances of the
generic, only to the generic itself. (You need to be able to say that a
generic is Pure so it can be withed and instantiated in a Pure package; but
that doesn't necessaryly make it Pure - that depends on the formals).

The pragma on the instance is not "confirming"; it gives the categorization.

See AI-00041 for a full discussion.

                          Randy.

Re: Elaboration of nested generic package.

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<vh8dpifpmicl78@corp.supernews.com>...
> 
> A library unit pragma that applies to a generic unit does not apply to its
> instances, unless a specific rule for the pragma specifies the contrary.
> 
> That means that a categorization pragma does not apply to instances of the
> generic, only to the generic itself. (You need to be able to say that a
> generic is Pure so it can be withed and instantiated in a Pure package; but
> that doesn't necessaryly make it Pure - that depends on the formals).
> 
> The pragma on the instance is not "confirming"; it gives the categorization.
> 
> See AI-00041 for a full discussion.

OK, that clears things up a bit.  But I'm still confused about what
pragma should be used on the instantiation.

For example, in the AI, there's this example:

with Op;

generic 
package GP is
   pragma Preelaborate;
   I : Integer := Op;
   ...
end GP;

The pragma states that the body of GP should be elaborated prior to
the elaboration of any non-preelaborated library units, which means
you can omit elaboration checks during instantiations of GP.

Fine, but then what categorization pragma should one use on the
instantiation of GP:

with GP;
pragma Elaborate_All (GP);
package P is new GP;
pragma What_Goes_Here(P); --???

We can't use Preelaborate on P, because it isn't preelaborateable
(even though GP is).  What would be the difference between using
Elaborate_Body and Elaborate_All on P?

Re: Elaboration of nested generic package.

[Randy Brukardt]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1ec946d1.0307160724.1ff7c5b5@posting.google.com...
> For example, in the AI, there's this example:
>
> with Op;
>
> generic
> package GP is
>    pragma Preelaborate;
>    I : Integer := Op;
>    ...
> end GP;
>
> The pragma states that the body of GP should be elaborated prior to
> the elaboration of any non-preelaborated library units, which means
> you can omit elaboration checks during instantiations of GP.
>
> Fine, but then what categorization pragma should one use on the
> instantiation of GP:
>
> with GP;
> pragma Elaborate_All (GP);
> package P is new GP;
> pragma What_Goes_Here(P); --???
>
> We can't use Preelaborate on P, because it isn't preelaborateable
> (even though GP is).  What would be the difference between using
> Elaborate_Body and Elaborate_All on P?

Nothing goes here (as you said, you can't put Pure or Preelaborate here, and
Elaborate_Body makes no sense for an instantiation). In any case, you don't
need to do anything anywhere for elaboration, because the generic body is
alway elaborated at the point of the instantiation (which is why you need
the elaboration check at the instantiation). See 12.3(20). So there can't be
an elaboration problem in some other unit with an instantiation.

                   Randy.

Re: Elaboration of nested generic package.

[Richard Riehle]

Randy Brukardt wrote:

>
> ... the generic body is always elaborated at the point of the instantiation
> ...

which turned out to be a clever trick, under Ada 83, for ensuring that
a package would be elaborated exactly when you needed it to be. We
would create generic packages with no parameters, with them, and
then instantiate them in any declaration part of a program, even in
a declare block.  Of course, this does raise an efficiency issue, but
it also solve an elaborartion issue.

Richard Riehle