* Elaborate_All on child package @ 2011-09-03 16:57 Rego, P. 2011-09-05 5:21 ` AdaMagica 2011-09-06 7:05 ` Egil Høvik 0 siblings, 2 replies; 10+ messages in thread From: Rego, P. @ 2011-09-03 16:57 UTC (permalink / raw) 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 <....> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-03 16:57 Elaborate_All on child package Rego, P. @ 2011-09-05 5:21 ` AdaMagica 2011-09-05 9:28 ` Georg Bauhaus 2011-09-10 19:24 ` Rego, P. 2011-09-06 7:05 ` Egil Høvik 1 sibling, 2 replies; 10+ messages in thread From: AdaMagica @ 2011-09-05 5:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-05 5:21 ` AdaMagica @ 2011-09-05 9:28 ` Georg Bauhaus 2011-09-10 19:24 ` Rego, P. 1 sibling, 0 replies; 10+ messages in thread From: Georg Bauhaus @ 2011-09-05 9:28 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-05 5:21 ` AdaMagica 2011-09-05 9:28 ` Georg Bauhaus @ 2011-09-10 19:24 ` Rego, P. 1 sibling, 0 replies; 10+ messages in thread From: Rego, P. @ 2011-09-10 19:24 UTC (permalink / raw) Thank you. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-03 16:57 Elaborate_All on child package Rego, P. 2011-09-05 5:21 ` AdaMagica @ 2011-09-06 7:05 ` Egil Høvik 2011-09-06 12:51 ` Robert A Duff 1 sibling, 1 reply; 10+ messages in thread From: Egil Høvik @ 2011-09-06 7:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-06 7:05 ` Egil Høvik @ 2011-09-06 12:51 ` Robert A Duff 2011-09-06 13:46 ` Niklas Holsti 0 siblings, 1 reply; 10+ messages in thread From: Robert A Duff @ 2011-09-06 12:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-06 12:51 ` Robert A Duff @ 2011-09-06 13:46 ` Niklas Holsti 2011-09-06 14:23 ` Robert A Duff 0 siblings, 1 reply; 10+ messages in thread From: Niklas Holsti @ 2011-09-06 13:46 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-06 13:46 ` Niklas Holsti @ 2011-09-06 14:23 ` Robert A Duff 2011-09-07 5:03 ` AdaMagica 0 siblings, 1 reply; 10+ messages in thread From: Robert A Duff @ 2011-09-06 14:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-06 14:23 ` Robert A Duff @ 2011-09-07 5:03 ` AdaMagica 2011-09-07 10:49 ` Georg Bauhaus 0 siblings, 1 reply; 10+ messages in thread From: AdaMagica @ 2011-09-07 5:03 UTC (permalink / raw) > 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.) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Elaborate_All on child package 2011-09-07 5:03 ` AdaMagica @ 2011-09-07 10:49 ` Georg Bauhaus 0 siblings, 0 replies; 10+ messages in thread From: Georg Bauhaus @ 2011-09-07 10:49 UTC (permalink / raw) 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 ...) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-10 19:24 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-03 16:57 Elaborate_All on child package Rego, P. 2011-09-05 5:21 ` AdaMagica 2011-09-05 9:28 ` Georg Bauhaus 2011-09-10 19:24 ` Rego, P. 2011-09-06 7:05 ` Egil Høvik 2011-09-06 12:51 ` Robert A Duff 2011-09-06 13:46 ` Niklas Holsti 2011-09-06 14:23 ` Robert A Duff 2011-09-07 5:03 ` AdaMagica 2011-09-07 10:49 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox