pragma Elaborate (Comp. Unit) question.

pragma Elaborate (Comp. Unit) question.

[Michael]

Hi All,

  2 questions:

  Should one ever *need* get an error message from a compiler that a
compilation unit needs to have a "pragma Elaborate" clause for another
unit?

  That is, if the compiler knows what the elaboration order needs to be
why can't it make the relavant deterministic change and proceed with a
warning?

  Is it because elaboratation is by definition non-deterministic and if
so why is it that way?

 FYI, I am using Vads Ada83.

-- Michael

Take out the "no_" and the "_spam" to reply

Re: pragma Elaborate (Comp. Unit) question.

[Robert Dewar]

In article <7i75ko$6km$1@front3.grolier.fr>,
  "Thierry Lelegard" <lelegard@club-internet.fr> wrote:
> The correct order of elaboration is deterministic but many
> cases cannot be detected during compilation, not even during
> link. The developer is the only one to know (sometimes he does
> even know :-))

Note that in most cases GNAT can determine a correct reliable
order of elaboration at compile/link time, and does not need
dynamic checks. See the chapter on elaboration issues in the
GNAT users guide for a complete description of the static
semantic model for elaboration used by default in GNAT.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: pragma Elaborate (Comp. Unit) question.

[Thierry Lelegard]

>   That is, if the compiler knows what the elaboration order needs to be
> why can't it make the relavant deterministic change and proceed with a
> warning?
> 
>   Is it because elaboratation is by definition non-deterministic and if
> so why is it that way?

The correct order of elaboration is deterministic but many
cases cannot be detected during compilation, not even during
link. The developer is the only one to know (sometimes he does
even know :-))

Example:
1) package A ...
2) with A; package body B ...
3) with B; package body C ...

Let's assume that B does not call any subprogram of A
during its elaboration. So, the author of B thinks that B
does not need a pragma Elaborate (A).

C calls some subprograms of B during its elaboration. So,
the author of C adds a pragma Elaborate (B). However, he/she
does not know that the body of B references A (he/she may even
not know the existence of A). Let's assume that the subprogram
of B which is called during elaboration of C calls a subprogram
of A.

The following elaboration order is valid for the binder but
will raise a program_error during the elaboration of C:

spec A
spec B
spec C
body B (before body C because of pragma elaborate)
body C (elab: calls B, which in turn calls A)
body A (no pragma told me to elaborate sooner)

In Ada 95, the pragma Elaborate_All fixes this: The author
of C would write pragma Elaborate_All (B). But you are using
Ada 83, too bad...

One brute force way of fixing the problem in Ada 83 is to add a
pragma elaborate for each "with" clause, everywhere. I even
once wrote a tool to do that automatically! But there can be
some circularity problems:

package A is...
package B is...
with B; package body A is...
with A; package body B is...

Although poor design, this is valid. Adding a pragma elaborate
everywhere would create a circularity which cannot be solved by
the binder. You have to know exactly which uses which during
elaboration and set only the required pragmas.

-Thierry
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: pragma Elaborate (Comp. Unit) question.

[Robert I. Eachus]

>   Should one ever *need* get an error message from a compiler that a
> compilation unit needs to have a "pragma Elaborate" clause for another
> unit?
> 
>   That is, if the compiler knows what the elaboration order needs to be
> why can't it make the relavant deterministic change and proceed with a
> warning?

    There is a very deep answer lurking here...  For most programs,
there exists an order of elaboration that can be discovered at compile
time and will never cause Program_Error to be raised.  Good compilers
will try to choose a workable order but for some programs, finding that
order is extremely hard in a computability sense.  I once wrote an
example of this where the "correct' order of elaboration depended on
whether or not Fermat's Last Theorem was true.  (Now that compilers can
get that one right, I'll have to come up with a different example. ;-)

    But it gets worse.  It is relatively trivial to write a program
where data input from the keyboard at run-time determines whether or not
a particular elaboration order works.  (I've seen Comp Sci 101 students
write such programs--without inteding to. ;-)  It is a little trickier,
but not much, to create a program where there are several possible
elaboration orders at compile time, and for each one there are inputs
that cause Program_Error, and others that don't.

    This is why pragma Elaborate, and in Ada 95, pragmas Elaborate_All
and Elaborate_Body, are there.  If the "correct" elaboration order for
your program depends on Fermat's Last Theorem, you can tell the compiler
what to do instead of relying on the compiler's built in theorem prover.

    Now back to the compile time error message.  This message is trying
to tell you that the compiler couldn't find a workable elaboration
order, but maybe if you give it a hint...  Of course, you often get the
message when the elaboration order is already overconstrained and what
you really need to do is to figure out how to remove some of the
dependencies.  The compiler is trying to be helpful and give you a clue
as to where the problem is, but usually if you get that message, finding
a workable order is hard.  (See above.)  Better is to restructure your
program so that it is easy.  This often involves spliting packages or
moving some initialization code into the main program.


                                        Robert I. Eachus

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

Re: pragma Elaborate (Comp. Unit) question.

[Robert Dewar]

In article <3749F3B9.202F7A13@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
 Better is to restructure your
> program so that it is easy.  This often involves spliting
packages or
> moving some initialization code into the main program.
>
>                                         Robert I. Eachus


Many legacy programs have a huge mess when it comes to
elaboration issues.

The simple rule for elaboration is the same as elsewhere
in Ada, your code should NOT depend on any knowledge of
what is in a body.

This means you need to use Elaborate_All to make sure that
all packages are elaborated as needed.

If you are starting with new code, by far the best approach is
to completely abandon the dynamic model of run time checking,
and use the default static model of GNAT, which guarantees a
correct elaboration order at compile time.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---