Re: Elaboration order

Re: Elaboration order

[Tucker Taft]

Ken Garlington (GarlingtonKE@lfwc.lockheed.com) wrote:
: Chris McKnight wrote:
: > 
: >  LRM References?  Hmm..  how about (taken from ANSI/MIL-STD-1815A-1983):
: > 
: >    7.3  paragraph 4 :
: >       "The elaboration of the body of a subprogram declared in the visible
: >        part of a package is caused by the elaboration of the body of the
: >        package.  Hence a call of such a subprogram by an outside program
: >        unit raises the exception PROGRAM_ERROR if the call takes place
: >        before the elaboration of the package body"

: So what does this mean in the following case:

: package Another_Example is

:   function Initial_Value return Integer;

: end;

: package body Another_Example is

:   function Initial_Value return Integer is begin return 0; end;

: end;

: with Another_Example;
: package Use_Example is

:   X : Integer := Another_Example.Initial_Value;

: end;

: Can I get a Program_Error on the initialization of X? If so,
: it would seem like there would need to be a pragma
: Elaborate for nearly every reference to every package
: exporting a subprogram!

You only need a pragma Elaborate[_All](pkg) if you call a subprogram 
from "pkg" as part of the *elaboration* of some other package.

If the calls only appear in subprogram bodies, rather than at
the package level, you shouldn't have any problem.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Elaboration order

[Ken Garlington]

Tucker Taft wrote:
> 
> You only need a pragma Elaborate[_All](pkg) if you call a subprogram
> from "pkg" as part of the *elaboration* of some other package.
> 
> If the calls only appear in subprogram bodies, rather than at
> the package level, you shouldn't have any problem.

OK. Keeping in mind that I need the answer in terms of Ada 83, then this
is what I think I've heard so far:

1. If, in a package specification, I refer to something in another
package specification that is not completely defined in the other spec,
I need a pragma Elaborate. "Something" can include:

  - any case where I need the sequence_of_statements in the package
    body to run prior to the use of the something, such as a variable
    in the spec which is set in the sequence_of_statements. This case,
    I think I always understood.

  - any subprogram (since, otherwise, I could get a Program_Error); although
    I guess it would have to be a function. This case, I didn't understand.

2. On the other hand, if I refer to a subprogram within another subprogram
   body, I don't have to use pragma Elaborate. Is there a spec reference for
   this? What about referring to a subprogram elsewhere in a package body?
   What about the sequence_of_statements case above?

I'm trying to write up an explanation of this issue for our users, since
I don't think we understood the extent to which pragma Elaborate was needed.
Any assistance in this area in the immediate future would be appreciated.

> 
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Cambridge, MA  USA

Re: Elaboration order

[Ted Dennison]

Ken Garlington wrote:
> 
> Chris McKnight wrote:
> >
> >  LRM References?  Hmm..  how about (taken from ANSI/MIL-STD-1815A-1983):
> >
> >    7.3  paragraph 4 :
> >       "The elaboration of the body of a subprogram declared in the visible
> >        part of a package is caused by the elaboration of the body of the
> >        package.  Hence a call of such a subprogram by an outside program
> >        unit raises the exception PROGRAM_ERROR if the call takes place
> >        before the elaboration of the package body"
> 
> So what does this mean in the following case:

... (code removed to placate facist newsreader)....

> Can I get a Program_Error on the initialization of X? If so,
> it would seem like there would need to be a pragma
> Elaborate for nearly every reference to every package
> exporting a subprogram!

Yes, and (depending on your style) Yes.

Generally, the rule is that subprogram calls are safe once the first
line of code in the main routine is reached. Any call to a subprogram 
in another package from the declarations and the body code of another
package (the part between the "begin" and the "end Use_Example;") and
I think just about ANYWHERE in a task, can potentially raise 
PROGRAM_ERROR (and is thus erronious w/o a pragma elaborate). Calls to
subprograms from pacakge specifications are particularly likely to 
raise this error. There are all sorts of subtleties I'm brushing 
over here, but this is the general idea.

Failure to account for this in the design phase can lead to problems
at a seemingly random future date. The code may just happen to
elaborate in the right order, but one day a unit will be added or
deleted, and (***BOOM!****).

The full description of how this is supposed to work (in Ada 83)
can be found in section 10.5 (Elaboration of Library Units) of 
the LRM.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Elaboration order

[Joe Wierzbowski]

In article 4FA9@lfwc.lockheed.com, Ken Garlington <GarlingtonKE@lfwc.lockheed.com> () writes:
>   < snip >
> 
> So what does this mean in the following case:
> 
> package Another_Example is
> 
>   function Initial_Value return Integer;
> 
> end;
> 
> package body Another_Example is
> 
>   function Initial_Value return Integer is begin return 0; end;
> 
> end;
> 
> with Another_Example;
> package Use_Example is
> 
>   X : Integer := Another_Example.Initial_Value;
> 
> end;
> 
> Can I get a Program_Error on the initialization of X? If so,
> it would seem like there would need to be a pragma
> Elaborate for nearly every reference to every package
> exporting a subprogram!

  Yes, you can get Program_Error on the initialization of X.

  The important point here for Ada 83 is that this requirement
  refers to declarative regions.  So your choices are:
  1) Add a pragma Elaborate for each subprogram called during a 
     declarative region or
  2) Don't make initial assignments using subprogram calls in a
     declarative region.  This is a common mistake, so much so
     that it may be worth adding a restriction against doing so 
     in a coding standard.  I can tell you that it's almost always
     the first thing to bite you during integration; there's always
     someone who has an elaboration order problem.  

  Another thing to note here is that Ada 95 provides convenient
  ways of elaborating every required package (See Robert Duff's
  posting).  

Re: Elaboration order

[AdaWorks]

Joe Wierzbowski (jwierzbo@hercii.lasc.lockheed.com) wrote:

:   2) Don't make initial assignments using subprogram calls in a
:      declarative region.  This is a common mistake, so much so
:      that it may be worth adding a restriction against doing so 
:      in a coding standard. 


            Now there's an interesting idea:

               pragma Restriction(No_Subprogram_Call_Initialization);

            HmmmMMMMMmmmmmm! I wonder about the implications of this.
            
            Language lawyers? ? ?

            Richard Riehle

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Elaboration order

[Robert A Duff]

In article <adaworksDouqCL.Hnp@netcom.com>,
AdaWorks <adaworks@netcom.com> wrote:
>               pragma Restriction(No_Subprogram_Call_Initialization);
>
>            HmmmMMMMMmmmmmm! I wonder about the implications of this.

I can think of some implications: It increases the probability of bugs
due to uninitialized variables.  It reduces readability, by requiring
constants to be declared as variables.

:-)

- Bob

Re: Elaboration order

[Robert Dewar]

Richard Riehle sais

"           Now there's an interesting idea:

              pragma Restriction(No_Subprogram_Call_Initialization);

           HmmmMMMMMmmmmmm! I wonder about the implications of this.

           Language lawyers? ? ?

           Richard Riehle"

Richard, have you looked closely at pragma Preelaborate? As I have noted
before, this seems worth exploring in this context. The question for you
is how would pragma Preelaborate differe from pragma Restriction (NSCI),
and is this difference important.

pragma Preelaborate is an important feature of Ada 95, one that everyone
should be throughly familiar with.

IO in Pure packages, debugging

[Laurent Guerby]

[subject changed]

Robert A Duff writes
: 
: In article <4xspevde88.fsf@leibniz.enst-bretagne.fr>,
: Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote:
: >   Here is a simple solution to this kind of problem :
: >
: >package Pure_IO is
: >   pragma Pure;
: >
: >   procedure Debug (Msg : in String);
: >   pragma Import (C, Debug);
: >
: >end Pure_IO;
: >
: >   Then do the dirty work  (body) in Ada (convention C)  or C.
: 
: Excellent idea!  Thanks.
: 
: Does it really work?  I mean you're sort of cheating here.  

   That's more that cheating, I play a "pervert" game here ;-)

: You've declared that the thing is Pure, but you've lied.  So the optimizer
: might play nasty tricks, like eliminating calls to Debug, if the only
: effect of Debug is its "side effect".
: I guess it's OK to cheat like that, since it's "merely" debugging code.
: But one has to be careful, in case one's optimizer is smarter that one
: is ;-).

   Just  put  "in  out"  instead   of "in"  to   avoid  this kind   of
optimization (but then you havve  to declare the messages as variables
somewhere, no big deal).

: >   It's true that the current GDB-GNAT has some weakpoints, but if you
: >add to your code (instead of plenty ugly "with Text_IO; Put_Line ...")
: >some "extra" procedures to set up complex data structures and to print
: >them (just like in the GNAT code anyway) it works quite well
: 
: Yes, I do add all kinds of printing routines, and call them from gdb
: when necessary.  My version of gdb, which might not be the latest,
: doesn't even know how to print strings.  It prints a pair of addresses,
: instead of the characters of the string.

   Just update it (20 minutes of compilation  ;-). The current version
is quite efficient,  the only problem is  for tagged types, but if you
have written some dump routines there's  no problem at all (worked for
me for tagged + tasking + multiple partitions).

[deleted]

: Thanks for the help.
: 
: - Bob

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada
--  "Use the Source, Luke. The Source will be with you, always (GPL)"
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project)
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat)

Re: Elaboration order

[Robert A Duff]

In article <dewar.827846300@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>pragma Preelaborate is an important feature of Ada 95, one that everyone
>should be throughly familiar with.

Yes, and pragma Pure is useful, too.

Unfortunately, I've had a great deal of trouble using Preelaborate and
Pure, because I always find myself wanting to put in some debugging
print-outs, and saying "with" of an I/O package poisons everything so I
can't use Preelab or Pure.  And there's no telling when you're going to
need a debugging print out.  And it's kind of a pain if you have to
*remove* a pragma Preelaborate during the process of finding one bug,
because that modification might introduce *another* bug, causing
confusion.

Gdb is not quite up to the point where I can use it all the time instead
of debugging print-outs.  (Of course, reading one's code is usually a
better way of tracking down bugs, but not always.)

- Bob

Re: Elaboration order

[Robert Dewar]

Bob said:

"Unfortunately, I've had a great deal of trouble using Preelaborate and
Pure, because I always find myself wanting to put in some debugging
print-outs, and saying "with" of an I/O package poisons everything so I
can't use Preelab or Pure.  And there's no telling when you're going to
need a debugging print out.  And it's kind of a pain if you have to
*remove* a pragma Preelaborate during the process of finding one bug,
because that modification might introduce *another* bug, causing
confusion."

This is very true. There are two solutions in the GNAT world. First
for this particular case, you can use Gnat.IO instead of Text_IO,
since Gnat.IO is preelaborated (we are not alowed to make
Text_IO preelaborated).

Secondly, a more general, though more devious solution is the debugging
flag -gnatdu which turns off all dependency checking for categorization
pragmas :-)

Re: Elaboration order

[Laurent Guerby]

Robert A Duff writes
: 
: Robert Dewar <dewar@cs.nyu.edu> wrote:
: >pragma Preelaborate is an important feature of Ada 95, one that everyone
: >should be throughly familiar with.
: 
: Yes, and pragma Pure is useful, too.
: 
: Unfortunately, I've had a great deal of trouble using Preelaborate and
: Pure, because I always find myself wanting to put in some debugging
: print-outs, and saying "with" of an I/O package poisons everything so I
: can't use Preelab or Pure.  And there's no telling when you're going to
: need a debugging print out.  And it's kind of a pain if you have to
: *remove* a pragma Preelaborate during the process of finding one bug,
: because that modification might introduce *another* bug, causing
: confusion.

   Here is a simple solution to this kind of problem :

package Pure_IO is
   pragma Pure;

   procedure Debug (Msg : in String);
   pragma Import (C, Debug);

end Pure_IO;

   Then do the dirty work  (body) in Ada (convention C)  or C. I don't
know if there's a pragma Import (Ada,  xxx). GNAT seems to compile it,
I haven't checked if Import (C, xxx) is legal in a Pure unit.
 
: Gdb is not quite up to the point where I can use it all the time instead
: of debugging print-outs.  (Of course, reading one's code is usually a
: better way of tracking down bugs, but not always.)

   It's true that the current GDB-GNAT has some weakpoints, but if you
add to your code (instead of plenty ugly "with Text_IO; Put_Line ...")
some "extra" procedures to set up complex data structures and to print
them (just like in the GNAT code anyway) it works quite well (even for
multiple  partitions or  multiple  tasks   if you   know what   you're
doing). BTW  report GDB problems according  to the  README file coming
with the GDB patch, this will help improving it.
   
: - Bob

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada
--  "Use the Source, Luke. The Source will be with you, always (GPL)"
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project)
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat)

Re: Elaboration order

[Robert A Duff]

In article <4xspevde88.fsf@leibniz.enst-bretagne.fr>,
Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote:
>   Here is a simple solution to this kind of problem :
>
>package Pure_IO is
>   pragma Pure;
>
>   procedure Debug (Msg : in String);
>   pragma Import (C, Debug);
>
>end Pure_IO;
>
>   Then do the dirty work  (body) in Ada (convention C)  or C.

Excellent idea!  Thanks.

Does it really work?  I mean you're sort of cheating here.  You've
declared that the thing is Pure, but you've lied.  So the optimizer
might play nasty tricks, like eliminating calls to Debug, if the only
effect of Debug is its "side effect".

I guess it's OK to cheat like that, since it's "merely" debugging code.
But one has to be careful, in case one's optimizer is smarter that one
is ;-).

>... I don't
>know if there's a pragma Import (Ada,  xxx). GNAT seems to compile it,
>I haven't checked if Import (C, xxx) is legal in a Pure unit.

Import(Ada) should work.

>: Gdb is not quite up to the point where I can use it all the time instead
>: of debugging print-outs.  (Of course, reading one's code is usually a
>: better way of tracking down bugs, but not always.)
>
>   It's true that the current GDB-GNAT has some weakpoints, but if you
>add to your code (instead of plenty ugly "with Text_IO; Put_Line ...")
>some "extra" procedures to set up complex data structures and to print
>them (just like in the GNAT code anyway) it works quite well

Yes, I do add all kinds of printing routines, and call them from gdb
when necessary.  My version of gdb, which might not be the latest,
doesn't even know how to print strings.  It prints a pair of addresses,
instead of the characters of the string.

>... (even for
>multiple  partitions or  multiple  tasks   if you   know what   you're
>doing). BTW  report GDB problems according  to the  README file coming
>with the GDB patch, this will help improving it.

I suppose I should be a good citizen and do that.  But reporting
debugger bugs is even more difficult than reporting compiler bugs.
Bleah.  And sometimes I'm not really sure it's a debugger bug.  For
example, I recently noticed gdb printed "false" for some Boolean
components of a packed record, but my print-out routine seemed to think
they were True, and I wasn't quite sure if the bug was in gdb, or my
program, or my print-out routines.  In that particular case, I wasn't
willing to spend hours tracking it down, once I found the "real" bug I
was looking for.

Thanks for the help.

- Bob

Re: Elaboration order

[Robert I. Eachus]

In article <314829CD.4FA9@lfwc.lockheed.com> Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes:

  > Can I get a Program_Error on the initialization of X? If so, it
  > would seem like there would need to be a pragma Elaborate for
  > nearly every reference to every package exporting a subprogram!

   Yes, annd no.  IF you call a function from one package in the spec of
some other package you certainly need a pragma Elaborate or pragma
Elaborate_All.   If such a function (or a procedure) is used in the
sequence of statements of the package body, or if you call subprograms
declared earlier in the package there, or if you initialize objects in
the package body using functions from some other package, you may need
the pragmas as well.

   BUT, and this is what makes it so painless, either your program
runs or you get PROGRAM_ERROR right off the bat, so leaving out a
(potentially) required pragma Elaborate is pretty harmless.  (Unless
you don't have a debugger that will tell you where the PROGRAM_ERROR
came from.)  

   If you prefer, you can choose not to initialize objects in packages
with function calls, and not to have sequences of statements in
package bodies, but that is throwing the baby out with the bath water.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Elaboration order

[Robert Dewar]

Robert Eachus said:

   Yes, annd no.  IF you call a function from one package in the spec of
some other package you certainly need a pragma Elaborate or pragma
Elaborate_All.   If such a function (or a procedure) is used in the
sequence of statements of the package body, or if you call subprograms
declared earlier in the package there, or if you initialize objects in
the package body using functions from some other package, you may need
the pragmas as well.


Too strong -- you do not need to worry about this if the unit containing
the function you are calling has a pragma Preelaborate, pragma Pure, or
pragma Elaborate_Body.

Re: Elaboration order

[Ken Garlington]

Robert I. Eachus wrote:
> 
>    BUT, and this is what makes it so painless, either your program
> runs or you get PROGRAM_ERROR right off the bat, so leaving out a
> (potentially) required pragma Elaborate is pretty harmless.

I have to tell you, a development philosophy that says, "Oh, well,
if I make a mistake, I'll see an exception" rubs me the wrong way.
Maybe I just don't have that Ada mindset...

Re: Elaboration order

[Ted Dennison]

Ken Garlington wrote:
> 
> Robert I. Eachus wrote:
> >
> >    BUT, and this is what makes it so painless, either your program
> > runs or you get PROGRAM_ERROR right off the bat, so leaving out a
> > (potentially) required pragma Elaborate is pretty harmless.
> 
> I have to tell you, a development philosophy that says, "Oh, well,
> if I make a mistake, I'll see an exception" rubs me the wrong way.
> Maybe I just don't have that Ada mindset...

Then I guess after 7 years of using Ada, I don't have the Ada mindset
either.

Again, the general rule is: don't call routines from other packages in
package specs, package body declarations, or package body code. If for
some reason you can't follow this rule, use a pragma elaborate. 

While dependance on order of elaboration (w/o pragma elaborate) is not
technicly erronious, I ding it every time I see it in a walkthrough.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Elaboration order

[Michel Gauthier]

In article <314EE48E.7F5A@escmail.orl.mmc.com>, Ted Dennison
<dennison@escmail.orl.mmc.com> wrote:

>>  Robert Dewar wrote:
>>  > 
>>  >  (snip)
>>  (snip)
>>  > This sounds VERY bogus, I would NEVER do this kind of initialization
>>  > at elaboration time -- this is NOT what elaboratoin is intended for,
>>  > but rather, in my book, a gross misuse of the concept!
>>  
>>  I completely agree, but it doesn't mean others won't do it. I was given
>>  some code to debug once which was crashing 4 HOURS into elaboration. 
>>  Who knows how long elaboration would have taken without the crash? 

Nevertheless, you should consider that object design, when combined with 
Ada "accessibility rules" imply greater importance given to elaboration.

For instance, deriving a tagged type is legal only at the same level as the
parent type. Assuming that many tagged types are (visibly or privately)
declared in some library package, all their childs are necessarily declared
in library packages. 

Ada-95 programs will therefore make greater use (than Ada-83) of
library elaborations. How can you design and code something like an option
mechanism (from command line or configuration files) that must initialise
before some type definition ?

Note that I lost the initial messages, and hence cannot give any opinion on
that particular case. I only suggest not to repeat the mistake
( classic about exceptions) of confusing possible misuses and absolute harm.
I guess we, industry programmers and academic teachers, have yet to
"elaborate" style rules about the new 95 features, among which the above
problems.

To conclude, I may envisage to agree with " this is not what elaboration is 
intended for" but I am not sure that " what elaboration is intended for" is
information common to everybody.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Elaboration order

[DenReimer]

Here's something that I'm trying to do in Ada83 and Ada95:

with GENERIC_PACKAGE;
package A_PKG is
   package INSTANCE is new GENERIC_PACKAGE ( ... );
   X : INTEGER := INSTANCE.SOME_FUNCTION;
end A_PKG;

The elaboration of X requires that the instantiated package INSTANCE be
elaborated first (both spec and body.)  The compiler will not let me use
pragma elaborate (INSTANCE);

It is not clear to me what the elaboration order should be in the case of
nested packages.  I would like to assume that for nested packages, the
elaboration is also nested.  In the case of generic instantiations, both
spec and body would be elaborated at the point of instantiation. 
Unfortunately, the LRM does not seem to make any requirements regarding
elaboration order for nested packages.  I've tried the above source code
with Ada/ED and an Alsys Ada83 compiler and it seems to work OK.

When I use gnat, I get a program error.  The Ada95 pragmas used for
controlling elaboration order seem to only apply to library units.  In the
example above, I believe that INSTANCE is a program unit but not a library
unit.  Is there some way I can force the elaboration of INSTANCE to occur
immediately?  The only other alternative I can think of is to create
another compilation unit just for the instantiation so that INSTANCE will
then be a library unit.

Thanks,
Dennis Reimer

Re: Elaboration order

[Tucker Taft]

DenReimer (denreimer@aol.com) wrote:
: Here's something that I'm trying to do in Ada83 and Ada95:

: with GENERIC_PACKAGE;
: package A_PKG is
:    package INSTANCE is new GENERIC_PACKAGE ( ... );
:    X : INTEGER := INSTANCE.SOME_FUNCTION;
: end A_PKG;

: The elaboration of X requires that the instantiated package INSTANCE be
: elaborated first (both spec and body.)  The compiler will not let me use
: pragma elaborate (INSTANCE);

You should write:
   with Generic_Package;
   pragma Elaborate(Generic_Package);

: It is not clear to me what the elaboration order should be in the case of
: nested packages.  I would like to assume that for nested packages, the
: elaboration is also nested.  In the case of generic instantiations, both
: spec and body would be elaborated at the point of instantiation. 

All true.

: Unfortunately, the LRM does not seem to make any requirements regarding
: elaboration order for nested packages.  

Not true.

: ... I've tried the above source code
: with Ada/ED and an Alsys Ada83 compiler and it seems to work OK.

: When I use gnat, I get a program error.  The Ada95 pragmas used for
: controlling elaboration order seem to only apply to library units.  

That's true in Ada 83 as well.

: ... In the
: example above, I believe that INSTANCE is a program unit but not a library
: unit.  Is there some way I can force the elaboration of INSTANCE to occur
: immediately?  

Your problem is not the elaboration of Instance.  It is the elaboration
of the body of Generic_Package.  You are falling afoul of the
elaboration check that takes place when you instantiate a generic,
which requires that the generic body has already been elaborated.

As a general rule, if a compilation unit has a "with" for a generic, 
it should also have a "pragma Elaborate" for it, if it contains 
any library-level instantiations of the generic.

By the way, you are in good company.  Several of the 2.0.1 ACVC tests
forget this general rule.

: ...
: Dennis Reimer

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Elaboration order

[Robert A Duff]

In article <4io8rn$gfn@newsbf02.news.aol.com>,
DenReimer <denreimer@aol.com> wrote:
>Here's something that I'm trying to do in Ada83 and Ada95:
>
>with GENERIC_PACKAGE;
>package A_PKG is
>   package INSTANCE is new GENERIC_PACKAGE ( ... );
>   X : INTEGER := INSTANCE.SOME_FUNCTION;
>end A_PKG;

You need pragma Elaborate[_All](Generic_Package), assuming the generic
itself doesn't have any pragma (like Elaborate_Body).  This has nothing
to do with your call -- there is a run-time check on *instantiation*.

Having done that, your call is fine.  There's never any need for these
pragmas in the nested case (in fact, they're illegal), since nested
things are elaborated right where they appear in the code.  And the spec
and body of an instance are elaborated at the point of the
instantiation.  So, if you get elaboration order problems in the nested
case, you don't use pragmas -- you just rearrange the code into a
correct order.

>...  I've tried the above source code
>with Ada/ED and an Alsys Ada83 compiler and it seems to work OK.
>
>When I use gnat, I get a program error.

That's the non-portability I was grumbling about in a previous post.
Don't blame gnat for this -- it just happened to choose a different
order than the other compilers.

- Bob

Re: Elaboration order

[Norman H. Cohen]

In article <DoKLs8.727@world.std.com>, bobduff@world.std.com
(Robert A Duff) writes: 

|> You need pragma Elaborate[_All](Generic_Package), assuming the generic
|> itself doesn't have any pragma (like Elaborate_Body).

Concerning the "[_All]": 

In fact, for a library generic unit, Elaborate is always sufficient,
since the elaboration of a generic body does not have any semantic effect
(other than to mark the generic body as ready for instantiation).  In
particular, it cannot call a subprogram or instantiate a generic with a
still-unelaborated body.  There is a small chance that Elaborate_All will
introduce too many constraints on the elaboration order, making it
impossible to find an acceptable order.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Elaboration order

[Robert Dewar]

Norm says:

"In fact, for a library generic unit, Elaborate is always sufficient,
since the elaboration of a generic body does not have any semantic effect
(other than to mark the generic body as ready for instantiation).  In
particular, it cannot call a subprogram or instantiate a generic with a
still-unelaborated body.  There is a small chance that Elaborate_All will
introduce too many constraints on the elaboration order, making it
impossible to find an acceptable order."

Actually we have found that pragma Elaborate_All *often* introduces
bogus circularities. Elaborate_All is pessimistic, it assumes that
every possible function call that could be made will be made. You
are certainly safe if EA works, but it may well be TOO pessimistic.
Indeed it was our early experience in GNAT with Elaborate_All that
lead to the suggestion to retain Elaborate as a non-obsolescent feature.

Re: Elaboration order

[Norman H. Cohen]

In article <4io8rn$gfn@newsbf02.news.aol.com>, denreimer@aol.com (DenReimer)
writes: 

|> Here's something that I'm trying to do in Ada83 and Ada95: 
|>
|> with GENERIC_PACKAGE;
|> package A_PKG is
|>    package INSTANCE is new GENERIC_PACKAGE ( ... );
|>    X : INTEGER := INSTANCE.SOME_FUNCTION;
|> end A_PKG;
|>
|> The elaboration of X requires that the instantiated package INSTANCE be
|> elaborated first (both spec and body.)  The compiler will not let me use
|> pragma elaborate (INSTANCE);
|>
|> It is not clear to me what the elaboration order should be in the case of
|> nested packages.  I would like to assume that for nested packages, the
|> elaboration is also nested.  In the case of generic instantiations, both
|> spec and body would be elaborated at the point of instantiation.
|> Unfortunately, the LRM does not seem to make any requirements regarding
|> elaboration order for nested packages.

RM83-7.2(3), RM95-7.1(8): "The elaboration of a package declaration
consists of the elaboration of its basic declarative items in the given
order."

RM83-12.3(17): "For the elaboration of a generic instantiation, ....
Finally, the implicitly generated instance is elaborated."
RM95-12.3(20) is more explicit: "Finally, the instance declaration and
body are elaborated."

Thus both the declaration and body of Instance are sure to be elaborated
before the declaration of X is elaborated.

|> When I use gnat, I get a program error.

Possibly from an attempt to instantiate the TEMPLATE before its GENERIC
BODY has been elaborated.  (See RM83-3.9(7), RM95-3.11(13).)
Change your context clause to: 

   with Generic_Package; pragma Elaborate(Generic_Package);

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Elaboration order

[Mark A Biggar]

In article <31494143.3825@lfwc.lockheed.com> Ken Garlington <garlingtonke@lfwc.lockheed.com> writes:
>Robert A Duff wrote:
>[the standard answer, except it didn't explain...]
>Why doesn't the subprogram body have to be elaborated before the call?

It does.

>Should I expect this problem anytime I call a subroutine? It seems
>counter-intuitive...

No, you only run into this problem when you try to call a routine during the
elaboration of a library unit.  E.g., when you call a function as part of
the initial expression of a package variable or when you call any routine
in the begin section of a package body.  Note that this is never a problem
with your main code as all library units are guarenteed to be elaborated
before the main routine is called, so any routine called after that time
won't run into this problem.

--
Mark Biggar
mab@wdl.loral.com

Re: Elaboration order

[Ken Garlington]

Mark A Biggar wrote:
> 
> In article <31494143.3825@lfwc.lockheed.com> Ken Garlington <garlingtonke@lfwc.lockheed.com> writes:
> >Robert A Duff wrote:
> >[the standard answer, except it didn't explain...]
> >Why doesn't the subprogram body have to be elaborated before the call?
> 
> It does.

Please cite the Ada 83 reference for this. I can't find it.

In fact, in general, for all respondents to this question, if you
say that pragma Elaborate is _not_ needed in a particular context,
please cite an 83 reference. I can't even find a reference that
says the body can be assured of the elaboration of its own spec!

Re: Elaboration order

[Norman H. Cohen]

In article <314D2E1C.5C72@lfwc.lockheed.com>, Ken Garlington
<garlingtonke@lfwc.lockheed.com> writes: 

|> In fact, in general, for all respondents to this question, if you
|> say that pragma Elaborate is _not_ needed in a particular context,
|> please cite an 83 reference. I can't even find a reference that
|> says the body can be assured of the elaboration of its own spec!

RM83-10.5(2): "The elaboration of these library units and of the
corresponding libarary unit bodies is performed in an order consistent
with the partial ordering defined by the with clauses (see 10.3)."

In other words, if compilation unit A must be compiled, according to the
rules of RM83-10.3, before compilation unit B, then it is guaranteed that
A will be elaborated before B.

However, if package Client has a with clause for package Provider, this
only guarantees that the DECLARATION of package Provider will be
elaborated before the declaration (and body) of package Client.  The BODY
of package Provider could be elaborated later.  If the elaboration of the
declaration or body of Client uses a facility provided by Provider, that
declaration or body should contain (in Ada 83) an Elaborate pragma for
Provider, to ensure that the BODY of Provider is also elaborated before
that compilation unit.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Elaboration order

[Cordes MJ]

As an aside to the RM discussion of this thread, how do I know 
that Ada compiler X will generate the correct (as defined in
the RM) elaboration order?

I know that ACVC tests do not guarantee correct code generation.
Is the ACVC suite more complete when it comes to elaboration? Is
there a standard benchmark used by compiler vendors? Or, for safety
critical functions, should I verify this for every application
build?

Thanks in advance.

Mike

--
---------------------------------------------------------------------
Michael J Cordes
Phone: (817) 935-3823
Fax:   (817) 935-3800
EMail: CordesMJ@lfwc.lockheed.com
---------------------------------------------------------------------

Re: Elaboration order

[Robert Dewar]

Mike says

"As an aside to the RM discussion of this thread, how do I know
that Ada compiler X will generate the correct (as defined in
the RM) elaboration order?

I know that ACVC tests do not guarantee correct code generation.
Is the ACVC suite more complete when it comes to elaboration? Is
there a standard benchmark used by compiler vendors? Or, for safety
critical functions, should I verify this for every application
build?"

Of course the ACVC suite does not guarantee that a compiler gets the
order of elaboration correct in every case. Your question seems to
imply that you expected the ACVC suite to guarantee correct code
generatoin and that the reason that it does not is that it is not
complete. This is a serious misconception. No test suite can ever
guarantee that a compiler has no errors -- indeed, except for very
trivial programs, no set of tests ever guarantees accuracy.

For safety critical applications, you cannot trust ANY aspect of a compiler
or any other tool that you use, and you need to carefully verify EVERYTHING
about your program -- at least, put it this way, if you write the code for
a plane that I will fly on, I will expect this!

Are there ACVC tests to test order of elaboration? Sure!
Do they help ensure that compilers are correct in this respect? Sure!
Do they guarantee that compilers are correct in this respect? NO!

Re: Elaboration order

[Cordes MJ]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Mike says

: "As an aside to the RM discussion of this thread, how do I know
: that Ada compiler X will generate the correct (as defined in
: the RM) elaboration order?

: I know that ACVC tests do not guarantee correct code generation.
: Is the ACVC suite more complete when it comes to elaboration? Is
: there a standard benchmark used by compiler vendors? Or, for safety
: critical functions, should I verify this for every application
: build?"

: Of course the ACVC suite does not guarantee that a compiler gets the
: order of elaboration correct in every case. Your question seems to
: imply that you expected the ACVC suite to guarantee correct code
: generatoin and that the reason that it does not is that it is not
: complete. This is a serious misconception. No test suite can ever
: guarantee that a compiler has no errors -- indeed, except for very
: trivial programs, no set of tests ever guarantees accuracy.


You are reading things into the question which were not there. I was simply 
asking if it was generally held that elaboration order algorithms are
safer or better tested than code generation algorithms.

: For safety critical applications, you cannot trust ANY aspect of a compiler
: or any other tool that you use, and you need to carefully verify EVERYTHING
: about your program -- at least, put it this way, if you write the code for
: a plane that I will fly on, I will expect this!

Not exactly - industry cannot afford to verify *all* aspects of a program.
Risks are identified and analyzed and base on the analysis, something may
be done (e.g., redundancy, backup systems, additional testing). This is
true for all systems which go on a plane - not just SW.

A good software specific example is branch level testing vs path testing.
We do not perform full path testing of our applications because it (path
testing) is not cost effective. We perform other cost effective testing
on the application to reduce any and all risks to reasonable levels.

: Are there ACVC tests to test order of elaboration? Sure!
: Do they help ensure that compilers are correct in this respect? Sure!
: Do they guarantee that compilers are correct in this respect? NO!

THANKS!
--
---------------------------------------------------------------------
Michael J Cordes
Phone: (817) 935-3823
Fax:   (817) 935-3800
EMail: CordesMJ@lfwc.lockheed.com
---------------------------------------------------------------------

Re: Elaboration order

[Ken Garlington]

Robert Dewar wrote:
> 
> Are there ACVC tests to test order of elaboration? Sure!
> Do they help ensure that compilers are correct in this respect? Sure!

I think Mike was saying, "Although I know that the ACVC can never
guarantee correct compilation, does it have tests that address elaboration
order?" It sounds like the answer (shorn of some of the heat) is "yes".
Could you perhaps e-mail Mike or myself a pointer as to where to find those
tests, so we can see how they work?

Re: Elaboration order

[Robert A Duff]

In article <4inpiv$alk@cliffy.lfwc.lockheed.com>,
Cordes MJ <l117593@cliffy.lfwc.lockheed.com> wrote:
>As an aside to the RM discussion of this thread, how do I know 
>that Ada compiler X will generate the correct (as defined in
>the RM) elaboration order?

You don't.  A compiler is a complex program, and probably has bugs.
FWIW, I've never seen this particular bug in an Ada implementation.
It's not very hard to get it right -- it's a fairly simple graph-walking
algorithm.  I *have* seen bugs in Ada compilers, but not this particular
bug.

>I know that ACVC tests do not guarantee correct code generation.

Yes, of course.  No test suite can be complete, since there are an
infinite number of possible Ada programs.

>Is the ACVC suite more complete when it comes to elaboration? 

I dunno.  I know there are *some* tests for this.

>...Is
>there a standard benchmark used by compiler vendors?

The ACVC.  Also, the ACEC or whatever it's called, which tests
performance, as opposed to conformance to the Standard.  Beyond that,
it's up to the compiler vendor to do whatever testing is deemed
necessary.

>...Or, for safety
>critical functions, should I verify this for every application
>build?

For safety critical functions, you should not trust your compiler.  You
should print out the machine code, and verify correctness at that level.
This is very expensive, of course.  But if lives are at stake (or large
amounts of money), that's what people do.  But there's nothing about
elaboration order issues that makes this a particularly error-prone
part.

- Bob

Re: Elaboration order

[Cordes MJ]

Robert A Duff (bobduff@world.std.com) wrote:
: In article <4inpiv$alk@cliffy.lfwc.lockheed.com>,
: Cordes MJ <l117593@cliffy.lfwc.lockheed.com> wrote:
: >As an aside to the RM discussion of this thread, how do I know 
: >that Ada compiler X will generate the correct (as defined in
: >the RM) elaboration order?

: You don't.  A compiler is a complex program, and probably has bugs.
: FWIW, I've never seen this particular bug in an Ada implementation.
: It's not very hard to get it right -- it's a fairly simple graph-walking
: algorithm.  I *have* seen bugs in Ada compilers, but not this particular
: bug.

: >I know that ACVC tests do not guarantee correct code generation.

: Yes, of course.  No test suite can be complete, since there are an
: infinite number of possible Ada programs.

: >Is the ACVC suite more complete when it comes to elaboration? 

: I dunno.  I know there are *some* tests for this.

: >...Is
: >there a standard benchmark used by compiler vendors?

: The ACVC.  Also, the ACEC or whatever it's called, which tests
: performance, as opposed to conformance to the Standard.  Beyond that,
: it's up to the compiler vendor to do whatever testing is deemed
: necessary.

: >...Or, for safety
: >critical functions, should I verify this for every application
: >build?

: For safety critical functions, you should not trust your compiler.  You
: should print out the machine code, and verify correctness at that level.
: This is very expensive, of course.  But if lives are at stake (or large
: amounts of money), that's what people do.  But there's nothing about
: elaboration order issues that makes this a particularly error-prone
: part.

Thanks for the input, but that doesn't help me quantify the risk. Scanning
the machine code for  a complex application (assume over 200 packages), looking
for a class of error which neither of us has seen, does not give me any
confidence that we would catch the error if it did show up. Some sort
of automated verification is a possibility, but I need a better understanding
of the risk before I propose a new tool. And getting a grasp on the risk
was the intent of my original post.

Is there anybody out there who is doing analysis on elaboration order?
: - Bob

--
---------------------------------------------------------------------
Michael J Cordes
Phone: (817) 935-3823
Fax:   (817) 935-3800
EMail: CordesMJ@lfwc.lockheed.com
---------------------------------------------------------------------

Re: Elaboration order

[Robert Dewar]

"Thanks for the input, but that doesn't help me quantify the risk. Scanning
the machine code for  a complex application (assume over 200 packages), looking
for a class of error which neither of us has seen, does not give me any
confidence that we would catch the error if it did show up. Some sort
of automated verification is a possibility, but I need a better understanding
of the risk before I propose a new tool. And getting a grasp on the risk
was the intent of my original post."

To minimize this risk, minimize or even eliminate ALL elaboration (it is
not out of the question to rquire pragma Preelaborate in all units for
a safety-critical application).

Re: Elaboration order

[Ken Garlington]

Robert Dewar wrote:
> 
> To minimize this risk, minimize or even eliminate ALL elaboration (it is
> not out of the question to rquire pragma Preelaborate in all units for
> a safety-critical application).

I agree with the sentiment, althought of course it _is_ somewhat counter-
productive to apply pragma Preelaborate to our current evnvironment, since we are
still using Ada 83!

I guess it's because of the rarity of a problem in this area, but I don't think
that this issue was addressed in the Ada (95) Quality and Style Guide, or other
generally-available style guides.

Also, I wonder if there's something here for a future revision of the safety
systems annex, or maybe as an HRG topic?

By the way, I am always amazed (pleasantly) at the volume and quality of answers
I get when I ask questions like this in c.l.a. Certainly worth the price!

Re: Elaboration order

[Robert A Duff]

In article <4ip58c$gqo@cliffy.lfwc.lockheed.com>,
Cordes MJ <l117593@cliffy.lfwc.lockheed.com> wrote:
>Thanks for the input, but that doesn't help me quantify the risk. Scanning
>the machine code for  a complex application (assume over 200 packages), looking
>for a class of error which neither of us has seen, does not give me any
>confidence that we would catch the error if it did show up. Some sort
>of automated verification is a possibility, but I need a better understanding
>of the risk before I propose a new tool. And getting a grasp on the risk
>was the intent of my original post.
>
>Is there anybody out there who is doing analysis on elaboration order?

Sorry if I'm being unhelpful, but:
Why are you so interested in elaboration order bugs, when there are
thousands of other bugs an Ada compiler *might* have?  I see no reason
why this one is more likely, or more harmful, than any other bug.
(Assuming we're talking about the sort of compiler bug that involves
incorrect behavior at run time.)

People who write safety critical programs really do analyze the machine
code, and that's extremely expensive.  Presumably, if the compiler used
a wrong elaboration order, then this analysis would catch it just like
any other bug (compiler bug *or* programmer bug) -- it would notice, for
example, a machine instruction loading from a location that has not yet
been set to any value.

- Bob

Re: Elaboration order

[Cordes MJ]

Robert A Duff (bobduff@world.std.com) wrote:
: In article <4ip58c$gqo@cliffy.lfwc.lockheed.com>,
: Cordes MJ <l117593@cliffy.lfwc.lockheed.com> wrote:
: >Thanks for the input, but that doesn't help me quantify the risk. Scanning
: >the machine code for  a complex application (assume over 200 packages), looking
: >for a class of error which neither of us has seen, does not give me any
: >confidence that we would catch the error if it did show up. Some sort
: >of automated verification is a possibility, but I need a better understanding
: >of the risk before I propose a new tool. And getting a grasp on the risk
: >was the intent of my original post.
: >
: >Is there anybody out there who is doing analysis on elaboration order?

: Sorry if I'm being unhelpful,

(and you're not being "unhelpful")

: but:
: Why are you so interested in elaboration order bugs, when there are
: thousands of other bugs an Ada compiler *might* have?  I see no reason
: why this one is more likely, or more harmful, than any other bug.
: (Assuming we're talking about the sort of compiler bug that involves
: incorrect behavior at run time.)

because elaboration order problems are a different class of bug (if one
of these bugs has ever existed). I can test typical code (for design
errors and code generation errors) given any number of main procedures.
It shouldn't matter if I use a special package (call it unclassified)
containing "dummy" data to test the functionality of some procedure.
The linker doesn't even have to instrument the code if I pass my data
into the procedure by parameter.

Errors introduced at link-time are not so well understood. These errors
could include elaboration order bugs or even the incorrect calculation
of the destination of a unit call. Just because I have never seen one
of these problems, doesn't mean that I shouldn't consider it. And that's
why I asked the question.

: People who write safety critical programs really do analyze the machine
: code, and that's extremely expensive.  Presumably, if the compiler used
: a wrong elaboration order, then this analysis would catch it just like
: any other bug (compiler bug *or* programmer bug) -- it would notice, for
: example, a machine instruction loading from a location that has not yet
: been set to any value.

I haven't seen an analysis tool which could catch the type of error which
we are talking about. And human analysis on complex systems is more prone
to error than the linker or compiler. In any event, if you don't see
elaboration order as a risk, then you will not do any analysis of it.

(and now I'm full circle - is elaboration order a risk? :-)

P.s., no one word answeres, please :-)

: - Bob

--
---------------------------------------------------------------------
Michael J Cordes
Phone: (817) 935-3823
Fax:   (817) 935-3800
EMail: CordesMJ@lfwc.lockheed.com
---------------------------------------------------------------------

Re: Elaboration order

[JP Thornley]

In article: <4ip58c$gqo@cliffy.lfwc.lockheed.com>  
l117593@cliffy.lfwc.lockheed.com (Cordes MJ) writes:
   [snip]
> Thanks for the input, but that doesn't help me quantify the risk. Scanning
> the machine code for  a complex application (assume over 200 packages), 
looking
> for a class of error which neither of us has seen, does not give me any
> confidence that we would catch the error if it did show up. Some sort
> of automated verification is a possibility, but I need a better understanding
> of the risk before I propose a new tool. And getting a grasp on the risk
> was the intent of my original post.
> 
> Is there anybody out there who is doing analysis on elaboration order?
> : - Bob
> 
> --
> ---------------------------------------------------------------------
> Michael J Cordes
> Phone: (817) 935-3823
> Fax:   (817) 935-3800
> EMail: CordesMJ@lfwc.lockheed.com
> ---------------------------------------------------------------------
> 
> 

FWIW, the safety critical code we write uses a subset that avoids any 
elaboration order dependencies (and there is a tool to ensure conformance to 
the subset).

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Elaboration order

[Robert Dewar]

JP Thornley writes

"FWIW, the safety critical code we write uses a subset that avoids any
elaboration order dependencies (and there is a tool to ensure conformance to
the subset)."

This seems a perfectly reasonable approach to me. Another is to eliminate
all possible ABE's by some uniform scheme. A fierce one (too fierce I
think, but it certainly does the job) is one that I heard was being
used in one giant project: always put pragma Elaborate for every with.
Of course this eliminates all ABE's, but also eliminates mutual recursion
between packages.

An interesting question for JP is how closely the subset corresponds
to the built in notion of pragma Preelaborate in Ada 95. I think it
is quite possible to consider using pragma Preelaborate for all
packages in such an implementation, and then the compiler acts as
the tool for enforcement without depending on implementatin dependent
features.

Re: Elaboration order

[JP Thornley]

In article: <dewar.827756008@schonberg>  dewar@cs.nyu.edu (Robert Dewar) 
writes:  (in response to a post about the use of subsets)
> 
> An interesting question for JP is how closely the subset corresponds
> to the built in notion of pragma Preelaborate in Ada 95.

A humble user replies:
If Robert thinks this is an interesting question, which I take to mean 
'not having any immediately obvious answer', then I'm certainly not going 
to attempt to come up with the definitive one :-)

(Isn't that what academics and tool suppliers are for?)

Phil Thornley
-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
| aka phil.thornley@bae.co.uk (but the .co doesn't                     |
| have newsgroup access so I'm doing this from home)                   |
------------------------------------------------------------------------

Re: Elaboration order

[Chris McKnight]

In article 5C72@lfwc.lockheed.com, Ken Garlington <garlingtonke@lfwc.lockheed.com> () writes:
>Mark A Biggar wrote:
>> 
>> In article <31494143.3825@lfwc.lockheed.com> Ken Garlington <garlingtonke@lfwc.lockheed.com> writes:
>> >Robert A Duff wrote:
>> >[the standard answer, except it didn't explain...]
>> >Why doesn't the subprogram body have to be elaborated before the call?
>> 
>> It does.
>
>Please cite the Ada 83 reference for this. I can't find it.
>
  Guess you didn't read my response.  The reference Ada 83 LRM reference
  is 7.3 paragraph 4, the key line being:

    "          ...a call of such a subprogram by an outside program 
     unit raise the exception PROGRAM_ERROR if the call takes place
     before the elaboration of the package body"

>In fact, in general, for all respondents to this question, if you
>say that pragma Elaborate is _not_ needed in a particular context,
>please cite an 83 reference.

  A reference to when something is NOT needed?  Would you expect
  such a thing?  Think about it; do you really expect a specific
  reference to when.. say NUMERIC_ERROR is NOT raised?

  Look at it this way, since all discussion in the LRM for pragma
  Elaborate lists the kind of cases you may need it for, the easiest
  way to determine that it is not needed is to determine that your
  code can not fall into one of these cases.  And since all of these
  cases involve actions which occur during elaboration, the easiest
  way to avoid it is not to make these type of assignments during
  elaboration.  This is especially true if you are directing others.
  It's far easier to say "No assignments of this type during elaboration"
  than to list when one may or may not need to use pragma Elaborate.

>                             I can't even find a reference that
>says the body can be assured of the elaboration of its own spec!

  The requirement for a spec to be elaborated before the body is in
  3.9 Declarative Parts.  Paragraph 3 states that the elaboration of
  a declarative part consists of the elaboration of the declarative items 
  "in the order in which they are given in the declarative part".

  And I think it's clear that the order given in the declarative part
  is required to be spec before body.  See 3.9 paragraph 9 for that 
  specific requirement for your example.

  But again, I ask, "Why worry about elaboration order problems when they
  are easily avoided?"

  Cheers,

     Chris

Re: Elaboration order

[Ken Garlington]

Chris McKnight wrote:
> 
> >> >Why doesn't the subprogram body have to be elaborated before the call?
> >>
> >> It does.
> >
> >Please cite the Ada 83 reference for this. I can't find it.
> >
>   Guess you didn't read my response.

Sorry, another ambiguous discussion here.

My question was: Does the language standard require (that is, directs the compiler
to always do it "correctly")  that the body be elaborated before the call?

Your answer was: The language standard does require (that is, will directs the
compiler to generate Program_Error if it didn't do it "correctly") that the body be
elaborated before the call.

My bad!

Re: Elaboration order

[Robert A Duff]

In article <31494143.3825@lfwc.lockheed.com>,
Ken Garlington  <garlingtonke@lfwc.lockheed.com> wrote:
>Robert A Duff wrote:
>
>[the standard answer, except it didn't explain...]
>
>Why doesn't the subprogram body have to be elaborated before the call?

Not sure what you're asking -- why was the language designed this way,
or why do the existing language rules imply this.

>Should I expect this problem anytime I call a subroutine? It seems
>counter-intuitive...

When you say "with P;", you are depending on the *spec* of P, and the
rules in chap 10 say that this spec will be elaborated before you.  You
do not depend on the *body* of P, so it might get elaborated later,
causing a nasty bug.  To fix it, you have to put in one of the
elaboration-controlling pragmas.

Now, if we said that "with P;" introduced a requirement that spec AND
BODY of P be elaborated earlier, then you couldn't write mutually
recursive packages -- e.g. body of P says "with Q;", and body of Q says
"with P;".  That's an important feature.

One could imagine other solutions, though.  During the design of Ada 95,
we considered trying to solve this problem, but it's not easy
(especially given the requirement for upward compatibility), and we
eventually just didn't do it.  It's a real problem, primarily because
you have no way of knowing whether this bug exists in your code -- your
compiler might just *happen* to elaborate things in an order that makes
your code work, but the bug appears when you use a different compiler,
or make some unrelated change in the with_clauses.

Here's one idea: By default, "with P;" means both spec and body of P get
elaborated before me.  If there are mutually-recursive packages, you
have to put in a special pragma that says, "don't bother elaborating the
body of P earlier than me".  I think turning it around this way would
reduce the number of cases where you have to put in a pragma, and would
make the safe case be the default.  This would not be upward compatible.

The designers of Ada 83 struggled with this issue.  In Ada 80 (or so),
the compiler was required to do an extraordinarily complex analysis at
link time, to determine the order, so there was no need for run-time
checks on calls.  This was changed in order to simplify implementation.

- Bob

Re: Elaboration order

[Robert Dewar]

"   That's quite an understatement.  To demonstrate the problem with
the Ada 80 rule I wrote a little program that any Ada 80 compiler must
compile without error if Format's Last Theorem was true, and which
must be rejected if it was false."

First, I love the typo (Format for Fermat) :-)

But another comment, this must mean that yoru program should compile
without error, as we now know :-)

Re: Elaboration order

[Robert Dewar]

"   More important, it is possible to write a legal (Ada 83 and 95)
program which reads input from a file, command line, or even a
terminal, before the main program is called.  If you work at it
(exercise left to the reader) it is possible to write the program so
that there are two different interesting and legal elaboration orders,
and inputs that cause Program_Error with one elaboration order excute
successfully with the other.  Of course, for toy examples, there is
an equivalent program which doesn't raise Program_Error.  But for
embedded applications, it can be the case that various peripherals
have to be brought on line in sequence and with fairly tight timing
requirements."

This sounds VERY bogus, I would NEVER do this kind of initialization
at elaboration time -- this is NOT what elaboratoin is intended for,
but rather, in my book, a gross misuse of the concept!

Re: Elaboration order

[Ted Dennison]

Robert Dewar wrote:
> 
> "   More important, it is possible to write a legal (Ada 83 and 95)
> program which reads input from a file, command line, or even a
> terminal, before the main program is called.  If you work at it
> (exercise left to the reader) it is possible to write the program so
> that there are two different interesting and legal elaboration orders,
> and inputs that cause Program_Error with one elaboration order excute
> successfully with the other.  Of course, for toy examples, there is ..."
(snip)
> This sounds VERY bogus, I would NEVER do this kind of initialization
> at elaboration time -- this is NOT what elaboratoin is intended for,
> but rather, in my book, a gross misuse of the concept!

I completely agree, but it doesn't mean others won't do it. I was given
some code to debug once which was crashing 4 HOURS into elaboration. 
Who knows how long elaboration would have taken without the crash? 

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Elaboration order

[David Emery]

In article <EACHUS.96Mar18143219@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

> In article <DoBI9D.KH6@world.std.com> bobduff@world.std.com (Robert A
Duff) writes:
> 
>   > The designers of Ada 83 struggled with this issue.  In Ada 80 (or so),
>   > the compiler was required to do an extraordinarily complex analysis at
>   > link time, to determine the order, so there was no need for run-time
>   > checks on calls.  This was changed in order to simplify implementation.
> 
>    That's quite an understatement.  To demonstrate the problem with
> the Ada 80 rule I wrote a little program that any Ada 80 compiler must
> compile without error if Format's Last Theorem was true, and which
> must be rejected if it was false.
> 
>    (Such a theorem prover being beyond the state of the art, the rules
> were changed for Ada 83 to allow the compiler to pick one arbitrary
> order.)
> 
...
> --
> 
>                                         Robert I. Eachus
> 
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...

Of course, there wasn't time to type in the program so Eachus scribbled
it down on the side of an old printout, which he has subsequently lost :-) :-)

               dave

Re: Elaboration order

[Norman H. Cohen]

In article <DoBI9D.KH6@world.std.com>, bobduff@world.std.com
(Robert A Duff) writes: 

|> The designers of Ada 83 struggled with this issue.  In Ada 80 (or so),
|> the compiler was required to do an extraordinarily complex analysis at
|> link time, to determine the order, so there was no need for run-time
|> checks on calls.  This was changed in order to simplify implementation.

"Extraordinarily complex" is an understatement.  As I recall, the
original wording required implementors to solve the halting problem.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Elaboration order

[Robert I. Eachus]

In article <314D2E1C.5C72@lfwc.lockheed.com> Ken Garlington <garlingtonke@lfwc.lockheed.com> writes:

  > In fact, in general, for all respondents to this question, if you
  > say that pragma Elaborate is _not_ needed in a particular context,
  > please cite an 83 reference.

    Can't possibly do that...  It is a halting problem issue to
determine if the elaboration order affects the final result of the
program.  (For almost all programs it won't, but it is very difficult
to prove.  Note that first you have to prove that your program never
does anything that in Ada 83 is erroneous.  The behavior of an
erroneous program often will depend on how things are layed out in
memory.)

  > I can't even find a reference that says the body can be assured of
  > the elaboration of its own spec!

   It can, because the specification of a unit is always elaborated
before the body due to the linear order of elaboration.  This applies
even to specs and bodies nested inside other units.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Elaboration order

[Robert I. Eachus]

In article <emery-1903962048300001@line130.nwm.mindlink.net> emery@grebyn.com (David Emery) writes:

  > Of course, there wasn't time to type in the program so Eachus scribbled
  > it down on the side of an old printout, which he has subsequently
  > lost :-) :-) 

   I did NOT, I actually threw it at a couple of Ada 80 compilers to
see what happened, but the compiles never finished. :-(  When Ada 83
compilers came along, they produced code which just sat there burning
cycles, and never got to the main program. (If there was a non-trivial
solution to A**N + B**N = C**N for N > 2, the program would eventually
raise Program_Error.  Since it was using an arbitrary precision
arithmetic package, it would probably have raised Storage_Error
eventually, but I never ran it that long.)

   However, the Ada 80 program that really got me in trouble was the
one that showed a flaw in one implementor's approach to elaboration of
accept entries.  With a pair of nested accepts for the same entry with
an unconstrained array parameter, I showed just what a bad an idea
that implemetation was.  Ada 83 and Ada 95 both have a prohibition of
nested accept statements for the same entry as a result.

    As a result I made a vow NEVER to put code on a blackboard or
overhead if I don't want people actually compiling it.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Elaboration order

[Robert I. Eachus]

In article <dewar.827204425@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

  > But another comment, this must mean that your program should compile
  > without error, as we now know :-)

   It does, and sits there elaborating for a long time.  But that is
because the Ada rules were changed.  If someone had ever managed to
validate an Ada 80 compiler I would have been the one writing "QED FLT."

   (Actually, I stated things backwards.  The program only gets
elboration error if it tries to print a counterexample, so it must
compile on an Ada 80 compiler if and only if FLT is true, which is now
believed to be proven.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Elaboration Order

[Wolf-Dieter Heker]

I think that Ada95 leaves too much freedom with respect to the elaborations
order of library units unless the user specifies lots of pragmas. This was
already the case in Ada83, although the introduction of elaborate_body
slightly improved the situation.
From my point of view, most of the library packages ever written are 'simple
ones', i.e. they need no special treatment with respect to elaboration
order.  Hence I would suggest that these packages should contain an
elaborate_body pragma (except, of course, if the have no body). But alas,
most programmers - including myself ;-) - do not write these pragmas until
the get into trouble.
The lack of these pragmas is a portability issue. And isn't it true that if
a package body cannnot be elaborated immediately after the spec we have
generally a doubtful design? (This is not to say there might be no reasons
for such a structure, just that it would be more the exception rathern than
the rule.)

Now my major question: Why didn't the language designers choose an approach
that would make the standard case easy and provide a pragma
defer_elaboration_of_body for those rare cases, where the user doesn't want
the body elaborated immediately after the spec? Is there more reason that
just compatibility with the user unfriendly definition of Ada83?

Wolf-Dieter Heker

Re: Elaboration Order

[Robert Dewar]

In article <FL8IuH.677@sd.aonix.com>,
  "Wolf-Dieter Heker" <heker@aonix.de> wrote:
> Hence I would suggest that these packages should contain an
> elaborate_body pragma (except, of course, if the have no
body). But alas,
> most programmers - including myself ;-) - do not write these
pragmas until
> the get into trouble.

Well then they are not following standard coding guidelines,
which is to use pragma Pure if possible, and if not possible,
use pragma Preelaborate, and if not possible use pragma
Elaborate_Body.

> The lack of these pragmas is a portability issue.

Of course the static elaboration model of GNAT eliminates this
portability issue, especially if you follow the ELaborate_All
guidelines suggested by -gnatwl.

> And isn't it true that if
> a package body cannnot be elaborated immediately after the
spec we have
> generally a doubtful design?

No, it is common to have package bodies that are mutually
recursive, and there is nothing whatsoever doubtful about
such a design.


> Now my major question: Why didn't the language designers
choose an approach
> that would make the standard case easy and provide a pragma
> defer_elaboration_of_body for those rare cases, where the user
doesn't want
> the body elaborated immediately after the spec?

Because they are not so rare

> Is there more reason that
> just compatibility with the user unfriendly definition of
> Ada83?

I see nothing especially unfriendly here, and it is not at
all obvious what the right solution is here. Programs that
use elaboration sparingly usually have little trouble. THe
supposedly user friendly suggestion you give of the defer
pragma would be a huge pain in the neck and result in piles
of pragmas for programs that do not need pragmas now.

Remember you only need elaborate pragmas if you actually call
routines during elaboration. Your pragma would need to be used
all over the place even in a program that HAD no elaboratoin
code at all.

To see an alternative approach, read the chapter on elaboration
in the GNAT RM.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration Order

[Wolf-Dieter Heker]

Robert Dewar <robert_dewar@my-deja.com> schrieb in im Newsbeitrag:
80pcdf$7u5$1@nnrp1.deja.com...
> In article <FL8IuH.677@sd.aonix.com>,
>   "Wolf-Dieter Heker" <heker@aonix.de> wrote:
> > Hence I would suggest that these packages should contain an
> > elaborate_body pragma (except, of course, if the have no
> body). But alas,
> > most programmers - including myself ;-) - do not write these
> pragmas until
> > the get into trouble.
>
> Well then they are not following standard coding guidelines,
> which is to use pragma Pure if possible, and if not possible,
> use pragma Preelaborate, and if not possible use pragma
> Elaborate_Body.

So you say, most packages should have one of these pragmas. I agree. But the
code I have seen so far does NOT contain them. I think that's real life. Do
you agree?

> > The lack of these pragmas is a portability issue.
>
> Of course the static elaboration model of GNAT eliminates this
> portability issue, especially if you follow the ELaborate_All
> guidelines suggested by -gnatwl.
>
> > And isn't it true that if
> > a package body cannnot be elaborated immediately after the
> spec we have
> > generally a doubtful design?
>
> No, it is common to have package bodies that are mutually
> recursive, and there is nothing whatsoever doubtful about
> such a design.

At least in this case, the author of the mutually dependent packages knows
about the fact and is clearly responsible to resolve the elaboration issue.

> > Now my major question: Why didn't the language designers
> choose an approach
> > that would make the standard case easy and provide a pragma
> > defer_elaboration_of_body for those rare cases, where the user
> doesn't want
> > the body elaborated immediately after the spec?
>
> Because they are not so rare
>
> > Is there more reason that
> > just compatibility with the user unfriendly definition of
> > Ada83?
>
> I see nothing especially unfriendly here, and it is not at
> all obvious what the right solution is here. Programs that
> use elaboration sparingly usually have little trouble.

They have little trouble until somebody tries to initialize a variable by a
function call, for example. Then he discovers that a whole system of
packages is incomplete with respect to elaboration pragmas. It is then not
sufficient to do a local change. It affects code that was considered ok
until then.

> THe supposedly user friendly suggestion you give of the defer
> pragma would be a huge pain in the neck and result in piles
> of pragmas for programs that do not need pragmas now.

Didn't you say above that 'following standard coding guidelines' every
package should contain one of the Pure, Preelaborate or Elaborate_Body
pragmas if possible. From that I conclude that the number of pragmas would
not be increased.

>
> Remember you only need elaborate pragmas if you actually call
> routines during elaboration. Your pragma would need to be used
> all over the place even in a program that HAD no elaboratoin
> code at all.
>
> To see an alternative approach, read the chapter on elaboration
> in the GNAT RM.

Can this be viewed online? I am one of those few people who haven't (yet)
installed GNAT.

>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: Elaboration Order

[David C. Hoos, Sr.]

Wolf-Dieter Heker <heker@aonix.de> wrote in message
news:FLABtD.MEw@sd.aonix.com...
>
<snip>
> Can this be viewed online? I am one of those few people who haven't (yet)
> installed GNAT.
>
Not that I know of, but you could download the doc only from

ftp://ftp.cs.nyu.edu/pub/gnat/gnat-3.12p-docs.tar.gz

This file contains (among other formats) the documentation in html format.

Re: Elaboration Order

[Robert Dewar]

In article <FLABtD.MEw@sd.aonix.com>,
  "Wolf-Dieter Heker" <heker@aonix.de> wrote:
> So you say, most packages should have one of these pragmas. I
agree. But the
> code I have seen so far does NOT contain them. I think that's
real life. Do
> you agree?


Well I cannot possibly disagree with a statement about code
that *you* have seen so far.

This means that you have not seen the GNAT runtime sources
I guess :-)

In practice we see quite a few customers adopting coding
guidelines for new Ada 95 code that include the requirements
for adding these pragmas where possible, and if you are using
Annex E, you quickly find the importance of doing so!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration Order

[Robert Dewar]

By the way, another important guideline in coding practice is
that if you call a function in elaboration code, or instantiate
a package in elaboration code, then you should have a
pragma Elaborate_All for the corresponding unit.

The use of pragma Elaborate is almost always wrong in new
Ada 95 code, though it may be hard to eliminate body
dependencies from legacy code (see GNAT users guide for
a long discussion of this point).

Another issue has to do with tasks. It is generally risky to
have library tasks starting at elaboration time, since it
means that you have arbitrary code running before the main
package elaboration is complete. If you create such tasks,
you must very carefully review them to make sure that they
do not cause elaboration problems.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration Order

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Another issue has to do with tasks. It is generally risky to
> have library tasks starting at elaboration time, since it
> means that you have arbitrary code running before the main
> package elaboration is complete. If you create such tasks,
> you must very carefully review them to make sure that they
> do not cause elaboration problems.

And your compiler (well, binder) may not be able to tell whether there
is an elaboration problem or not; _you_ may know that the task only
makes a problematic call after it has been allowed to start via some
rendezvous, which won't happen until the whole program has elaborated,
but the _compiler_ may not.

The cases where I've had this problem have both felt a bit
unsatisfactory when I reviewed the design.

Re: Elaboration Order

[Robert Dewar]

In article <x7vn1s9ouiu.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> And your compiler (well, binder) may not be able to tell
> whether there is an elaboration problem or not; _you_ may know
> that the task only makes a problematic call after it has been
> allowed to start via some rendezvous, which won't happen until
> the whole program has elaborated, but the _compiler_ may not.
>
> The cases where I've had this problem have both felt a bit
> unsatisfactory when I reviewed the design.

In GNAT, we have recently added the Restrictions pragma

  pragma Restrictions (No_Entry_Calls_In_Elaboration_Code);

This is checked statically by the compiler. It corresponds to
pretty much the normal situation in most programs. It is not
uncommon to have tasks start at elaboration time which
immediately hang on an accept. It is much less usual to start
these tasks off for real during elaboration by making entry
calls.

In the presence of this restrictions pragma (which could almost
be the default, we discussed making it the default in fact, but
decided against it), the compiler knows that such task bodies
do not get beyond the first accept, and thus we can ignore
elaboration issues from calls in subsequent code.

A bit kludgy, but then the whole idea of starting tasks at
elaboration time, which are free to do anything before the
rest of the program is fully elaborated is a nasty one, and
this kind of thing is not easily consistent with static
elaboration.

That being said, if you follow the general design principles
of:

  1. Never start stand alone tasks in elaboration code

  2. Always define separate task types

  3. Put the instances of tasks in separate units from the task
     types.

You can most often get a reliable static elaboration order
without needing this restrictions pragma. The above principles
seem good ones to me in any case, and probably relate to the
"felt a bit unsatisfactory" in above above quote



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration Order

[Mats Weber]

Robert Dewar wrote:

> In GNAT, we have recently added the Restrictions pragma
> 
>   pragma Restrictions (No_Entry_Calls_In_Elaboration_Code);
> 
> This is checked statically by the compiler. [...]

How can you check this statically ? What if elaboration code calls a
procedure in another package whose body has not yet been compiled, and
that procedure in turn makes an entry call ?

Re: Elaboration Order

[Jean-Pierre Rosen]

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


Wolf-Dieter Heker <heker@aonix.de> a �crit dans le message :
FL8IuH.677@sd.aonix.com...
> And isn't it true that if
> a package body cannnot be elaborated immediately after the spec we have
> generally a doubtful design? (This is not to say there might be no reasons
> for such a structure, just that it would be more the exception rathern
than
> the rule.)
>
There is (at least) one important case where this is not true:
if the body of a parent package wants to "with" its children (a common
situation with subsystems), then the specifications of the child units must
be elaborated between the parent's spec and the parent's body.
It is by the way quite annoying not to have an ELABORATE_FAMILY pragma...

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

Re: Elaboration Order

[Robert Dewar]

In article <80p0au$6n1$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> It is by the way quite annoying not to have an
ELABORATE_FAMILY pragma...

I know the vague thought here, but I don't see the details you
have in mind. Why not write it up and submit to the ARG, and
also post here.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration Order

[Jean-Pierre Rosen]

From: Robert Dewar <robert_dewar@my-deja.com>
> In article <80p0au$6n1$1@wanadoo.fr>,
>   "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> > It is by the way quite annoying not to have an
> ELABORATE_FAMILY pragma...
>
> I know the vague thought here, but I don't see the details you
> have in mind. Why not write it up and submit to the ARG, and
> also post here.
>
The "vague idea" is that if I put all my stuff in a single package, I can
put a pragma Elaborate_Body, and then every use of my package will be safe
(as far as elaboration is concerned), without requiring anything else from
the user of the package.

This does not hold any more if I decide to split my implementation into
child units. What is needed is a kind of Elaborate_Body that would provide
the same guarantee over the whole tree.

A possible definition of a pragma Elaborate_Family would be the same as a
pragma Elaborate_All on the body, with the additionnal constraint that no
unit should be elaborated between the elaboration of the specification and
the one for the body, other than those required by Elaborate_Family.

Alternatively, it could be defined as meaning that all descendants of the
unit should be elaborated after the specification, in an implementation
defined order, but before any unit which is not a descendant of the unit.

This is obviously just a first shot. Does it hold water ? Comments welcome.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog
.

Re: Elaboration Order

[Simon Wright]

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

> Alternatively, it could be defined as meaning that all descendants of the
> unit should be elaborated after the specification, in an implementation
> defined order, but before any unit which is not a descendant of the unit.

Well, perhaps only those descendants of the unit actually in this closure?

Re: Elaboration order

[Chris McKnight]

In article 1F9@world.std.com, bobduff@world.std.com (Robert A Duff) writes:
>In article <EACHUS.96Mar15174620@spectre.mitre.org>,
>Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>>   BUT, and this is what makes it so painless, either your program
>>runs or you get PROGRAM_ERROR right off the bat, so leaving out a
>>(potentially) required pragma Elaborate is pretty harmless.
>
>True during development on a particular platform.  But what bugs me
>about these rules is that the mysterious Program_Error can pop up when
>you port the program to a different compiler.  (Or, less likely, a new
>version of the same compiler.)
     
     ... or when you add new functionality on the same platform either
  during incremental development or maintenance.  It is not uncommon
  for a program to suddenly develop elaboration order problems simply
  by recompiling a library unit or two, even if that unit does not
  itself have the problem.  I've seen this several times, the compilation
  causes a change in the elaboration order which causes a side effect of
  making some other library unit get an elaboration order problem.
  And, since we're talking Ada 83 here, it can be difficult to track
  down the possibly nested library units to which you'll need to add
  pragma Elaborate.  So, as you can see, using subprogram calls during
  declarative regions can be far from painless.

    These type of problems have lead me to avoid assignments during 
  elaboration using subprogram calls.  Why invite trouble when it's 
  easily avoided?  I'll take controlled behaviour of initialization
  through Initialization procedures over unpredictable elaboration
  order dependencies any day.

  Just my $.02

  Cheers,

    Chris
  

Re: Elaboration order

[Jean-Pierre Rosen]

I'm surprised nobody mentionned this (or did I miss it?). If you know the
body of the package does not have any cross-calls at elaboration (which is
the common case), put a pragma Elaborate_Body in the spec.
The body will then be elaborated immediately after the sepc, so no user of
the package will run into problems with elaboration order.
BTW: this is Ada 95 of course, but  putting the pragma in an Ada 83 program
will not harm...
+------------------------------------o-------------------------------------+
| P-mail:                            | E-mail: rosen@enst.fr               |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+

Re: Elaboration order

[Ken Garlington]

Jean-Pierre Rosen wrote:
> 
> ...put a pragma Elaborate_Body in the spec. ... putting the pragma
> in an Ada 83 program will not harm...

True, but it won't help, either. We hit this problem with an Ada 83 compiler. :(