Elaborate_All on child package

Elaborate_All on child package

[Rego, P.]

Hi, 
I'm trying to create a child package from a package which have a class, but it needs the pragma Elaborate_All so 

package Forum_Test is
   type Small_Class;
   type Small_Class_Acc is access all Small_Class;
   task type My_Task_Type (This_Small_Class : access Small_Class);
   type Small_Class is tagged limited
      record
         My_Task      : My_Task_Type (Small_Class'Access);
      end record;

   function Construct return Small_Class_Acc;
end Forum_Test;

package Forum_Test.Childp is
   Small_Obj : Small_Class_Acc := Construct;
end Forum_Test.Childp;

and I got the messages
forum_test-childp.ads:2:35: info: call to "Construct" during elaboration
forum_test-childp.ads:2:35: info: implicit pragma Elaborate_All for "Forum_Test" generated
forum_test-childp.ads:2:35: warning: call to "Construct" in elaboration code requires pragma Elaborate_All on "Forum_Test"

So I included a pragma Elaborate_All in the beginning of the file, but got the 
message
forum_test-childp.ads:1:23: argument of pragma "Elaborate_All" is not withed unit

And finally I 'withed' the child package and it worked as well.

However, should it be done this way? Due to it is already "withed" to the parent package, so why have I make a new with? I mean: why is the following code incorrect:
   pragma Elaborate_All (Forum_Test);
   package Forum_Test.Childp is <....>

and why is the following code correct?
   with Forum_Test;
   pragma Elaborate_All (Forum_Test);
   package Forum_Test.Childp is <....>

Re: Elaborate_All on child package

[AdaMagica]

On 3 Sep., 18:57, "Rego, P." <pvr...@gmail.com> wrote:
> However, should it be done this way? Due to it is already "withed" to the parent package, so why have I make a new with? I mean: why is the following code incorrect:
>    pragma Elaborate_All (Forum_Test);
>    package Forum_Test.Childp is <....>
>
> and why is the following code correct?
>    with Forum_Test;
>    pragma Elaborate_All (Forum_Test);
>    package Forum_Test.Childp is <....>

The simple (and unsatisfying) answer: Because the RM says so.

So your problem is based on lack of understanding of elaboration. A
program begins execution by elaborating all compilation units. There
is no order prescribed for this except that what is mentioned in a
context clause must be elaborated before.

So applied to your example, elaboration order can be:

1. Forum_Test'Spec
2. Forum_Test'Body
3. Forum_Test.Childp'Spec
With this sequence, your program would have worked. However your
compiler, GNAT, chose another sequence:

1. Forum_Test'Spec
2. Forum_Test.Childp'Spec
3. Forum_Test'Body
When Childp calls Construct, you get an elaboration check that fails.

There are several ways to force certain elaboration orders. One is to
use pragma Elaborate_Body in every spec whenever the spec defines a
function - this forces the body to be elaborated directly after the
spec. Sometimes, this is not possible.

Other pragmas are Preelaborate, Elaborate_All, Elaborate, Pure. See RM
10.2.1 Elaboration Control.

Re: Elaborate_All on child package

[Georg Bauhaus]

On 05.09.11 07:21, AdaMagica wrote:

> Other pragmas are Preelaborate, Elaborate_All, Elaborate, Pure. See RM
> 10.2.1 Elaboration Control.

Side note: in order to write better Ada programs when using
GNAT, run the compiler with -gnatl -gnatE every now and then.

Do so and have GNAT tell you about parts of your program that
depend on elaboration order.  (The final executable may not need
the switches.)

Re: Elaborate_All on child package

[Rego, P.]

Thank you.

Re: Elaborate_All on child package

[Egil Høvik]

On Saturday, September 3, 2011 6:57:16 PM UTC+2, Rego, P. wrote:
> However, should it be done this way? Due to it is already "withed" to the parent package, so why have I make a new with? I mean: why is the following code incorrect:
>    pragma Elaborate_All (Forum_Test);  

Forum_Test is unknown. It is not defined in this scope.

>    package Forum_Test.Childp is <....>

Implicit with happens here, after Elaborate_All

> 
> and why is the following code correct?
>    with Forum_Test;
>    pragma Elaborate_All (Forum_Test);
>    package Forum_Test.Childp is <....>

Here, Forum_Test is known to the pragma, due to the explicit with.

Would you expect this to compile:

pragma Elaborate_All(Forum_Test);
with Forum_Test;



-- 
~egilhh

Re: Elaborate_All on child package

[Robert A Duff]

Egil H�vik <egilhovik@hotmail.com> writes:

> On Saturday, September 3, 2011 6:57:16 PM UTC+2, Rego, P. wrote:
>> However, should it be done this way? Due to it is already "withed" to the parent package, so why have I make a new with? I mean: why is the following code incorrect:
>>    pragma Elaborate_All (Forum_Test);  
>
> Forum_Test is unknown. It is not defined in this scope.

Right.  The visibility rules in context clauses are special.
They have to be, because the context clause are determining what's
visible elsewhere.  Why Jean Ichbiah chose this exact design,
I don't know.  I would have put the 'with' clauses inside the
package.

>>    package Forum_Test.Childp is <....>
>
> Implicit with happens here, after Elaborate_All

Nitpick:  There is no such thing as an "implicit with" in Ada.
The semantics of parent/child units are defined in terms
of the child being _inside_ the parent.  That is, Forum_Test
is visible in Childp because Childp is inside Forum_Test,
not because of an "implicit with".

Inside Childp, things declared in Forum_Test are directly visible.
If the semantics were defined in terms of "implicit with", then
you would have to say "use Forum_Test;" to make those things
directly visible.  Also, things declared in the private part
of Forum_Test are directly visible in (parts of) Childp;
they wouldn't be visible at all in the "implicit with" semantics.

>> and why is the following code correct?
>>    with Forum_Test;
>>    pragma Elaborate_All (Forum_Test);
>>    package Forum_Test.Childp is <....>
>
> Here, Forum_Test is known to the pragma, due to the explicit with.

Right.

> Would you expect this to compile:
>
> pragma Elaborate_All(Forum_Test);
> with Forum_Test;

Right, that's illegal.

- Bob

Re: Elaborate_All on child package

[Niklas Holsti]

Robert A Duff wrote:

> Right.  The visibility rules in context clauses are special.
> They have to be, because the context clause are determining what's
> visible elsewhere.  Why Jean Ichbiah chose this exact design,
> I don't know.  I would have put the 'with' clauses inside the
> package.

If the 'with' clauses would be inside the package, you would have to 
change also the location of the generic formals for generic packages, 
wouldn't you? The declarations of the formals should be able to refer to 
entities in 'withed' packages.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Elaborate_All on child package

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Robert A Duff wrote:
>
>> Right.  The visibility rules in context clauses are special.
>> They have to be, because the context clause are determining what's
>> visible elsewhere.  Why Jean Ichbiah chose this exact design,
>> I don't know.  I would have put the 'with' clauses inside the
>> package.
>
> If the 'with' clauses would be inside the package, you would have to
> change also the location of the generic formals for generic packages,
> wouldn't you? The declarations of the formals should be able to refer to
> entities in 'withed' packages.

You wouldn't have to, but you'd want to.

Note that Ada has always allowed forward references:

generic
   type Formal_Type is (<>);
   with procedure P (X : My_Generic.Formal_Type);  <-- This is legal!
package My_Generic is
end My_Generic;

which is a bit strange, given that Ada doesn't allow forward references
in general.

Anyway, generic formal parameters are analogous to a procedure's formal
parameters -- in both cases, they ought to come after the name of the
thing being declared.

- Bob

Re: Elaborate_All on child package

[AdaMagica]

> Robert A Duff wrote:
>
>> Right.  The visibility rules in context clauses are special.
>> They have to be, because the context clause are determining what's
>> visible elsewhere.  Why Jean Ichbiah chose this exact design,
>> I don't know.  I would have put the 'with' clauses inside the
>> package.

I guess he wanted them to stand out and not be hidden somewhere
inside.

> Note that Ada has always allowed forward references:
>
> generic
>    type Formal_Type is (<>);
>    with procedure P (X : My_Generic.Formal_Type);  <-- This is legal!
> package My_Generic is
> end My_Generic;
>
> which is a bit strange, given that Ada doesn't allow forward references
> in general.
>
> Anyway, generic formal parameters are analogous to a procedure's formal
> parameters -- in both cases, they ought to come after the name of the
> thing being declared.

Perhaps. I guess this special syntax was used because of the different
kind of parameters. In Ada 83, there were no subprogram parameters, so
since for generics, there are these kind of formals, Ichbiah chose
special syntax. Today, with subprogram parameters existing (but still
no type parameters), syntax decisions could have been different.

(I gather, with all the syntax and semantics discussions in this
group, we would have at least 100 different Adas if we were to start
from scratch.)

Re: Elaborate_All on child package

[Georg Bauhaus]

On 07.09.11 07:03, AdaMagica wrote:

> (I gather, with all the syntax and semantics discussions in this
> group, we would have at least 100 different Adas if we were to start
> from scratch.)

(Yet, hardly anyone bothers to arrive at the necessary rationality,
attention, and consistency when it comes to syntax: there are few
attempts at establishing a comprehensive set of criteria for judging
the qualities of different syntaxes. So as to have something before
considering the technical effects, viz. parsers.
 The discussions show that "scientists", engineers, and mathematicians
are, with a gesture, "skeptical of" (stunningly resistant to)
looking at the effects of their preferred form of expression.
Effects that form is bound to have in the hands and eyes of others.
 This is at odds with how scientific people are expected to work.
 From facts.
Where facts refers to syntax as a tool that functions, more or less,
in the hands of programmers, and programs' readers in particular.
You would expect scientists to use scientific methods in order
to arrive at criteria. Look at the data. Find meaning in the
data. Create model simulations of interpretations of data.
Perform experiments. But do all this with data collected about
syntax? No, they would not just lack experience in doing this, they
also refuse, it seems, to have their preferences judged by tests.
 A notable exception was when someone studied real data (coding
rules). Following scientific tradition, he first arrived at a
classification, categories A and B. Roughly, A is typographical
rules and B is rules concerning parts of a language that have
somehow shown to be a source of errors. He has produced results
that influence safety critical embedded systems programming
in C, as far as I can tell ...)