* generic package dilemma @ 1999-11-17 0:00 Riyaz Mansoor 1999-11-17 0:00 ` Matthew Heaney 0 siblings, 1 reply; 44+ messages in thread From: Riyaz Mansoor @ 1999-11-17 0:00 UTC (permalink / raw) hi hi i'm working on a problem which requires me to use many packages. the design i've made is like this. i've not given the details of the packages or data structures as i think the problem is not in them but rather in the way i'm initialising. ============================================== the main procedure initialises "gen_pack1" and "gen_pack4" as below -- main procedure with gen_pack1; with gen_pack4; procedure main is package pack1 is new gen_pack1; use pack1; package pack4 is new gen_pack4; use pack4; blah blha begin blah end main; ============================================== "gen_pack1" initialises "gen_pack2" and "gen_pack3" as below. -- gen_pack1 with gen_pack2; with gen_pack3; package gen_pack1 is package pack2 is new gen_pack2; use pack2; package pack3 is new gen_pack3; use pack3; blah blah end gen_pack1; the above works fine (as i see it). main instantiates pack1, and then pack1 instantiates pack2 & pack3. the main does recieve a valid variable from pack1 (and therfore pack2 and pack3). heres the problem. this variable is now passed int pack4 from the main. pack4 NEEDS functions and procedures in pack2 and pack3 to manipulate the variable. at the moment i've set pack4 as below and it does NOT work -- gen_pack4 with gen_pack2; with gen_pack3; package gen_pack4 is -- create copy package pack21 is new gen_pack2; use pack21 package pack31 is new gen_pack3; use pack31; blah blah end gen_pack4; it gives a type error! says that expected type is pack2.(type) but found type is pack21.(type). same for the other package. i even tried using the same names (stupid maybe) but to no avail. how can i get out of this? or is this a major design flaw? NOTE: when i remove the genrics all packages work fine and give the correct output. riyaz ---------------------------------------------------- AND THEN THEIR WAS LIGHT ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 generic package dilemma Riyaz Mansoor @ 1999-11-17 0:00 ` Matthew Heaney 1999-11-17 0:00 ` Mats Weber ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Matthew Heaney @ 1999-11-17 0:00 UTC (permalink / raw) In article <80u48b$ghr$1@bunyip.cc.uq.edu.au> , "Riyaz Mansoor" <s800032@student.uq.edu.au> wrote: > the main procedure initialises "gen_pack1" and "gen_pack4" as below > > -- main procedure > with gen_pack1; > with gen_pack4; You should always elaborate packages that you instantiate: pragma Elaborate (Gen_Pack1); pragma Elaborate (Gen_Pack4); > procedure main is > package pack1 is new gen_pack1; use pack1; > package pack4 is new gen_pack4; use pack4; > blah blha > begin > blah > end main; > > ============================================== > "gen_pack1" initialises "gen_pack2" and "gen_pack3" as below. > > -- gen_pack1 > with gen_pack2; > with gen_pack3; > package gen_pack1 is > package pack2 is new gen_pack2; use pack2; > package pack3 is new gen_pack3; use pack3; > blah blah > end gen_pack1; > > > the above works fine (as i see it). main instantiates pack1, and then pack1 > instantiates pack2 & pack3. the main does recieve a valid variable from > pack1 (and therfore pack2 and pack3). > > heres the problem. this variable is now passed int pack4 from the main. > pack4 NEEDS functions and procedures in pack2 and pack3 to manipulate the > variable. at the moment i've set pack4 as below and it does NOT work That's because these are different instantiations of Gen_Pack2 and Gen_Pack3. The solution is to have Gen_Pack4 import the instantiations, instead of making its own: > -- gen_pack4 > with gen_pack2; > with gen_pack3; generic with package Pack2 is new Gen_Pack2 (<>); with package Pack3 is new Gen_Pack3 (<>); > package gen_pack4 is > -- create copy > blah blah > end gen_pack4; > > it gives a type error! Yes, of course it does. Because these are different types! Now, during your instantiation of Gen_Pack4, pass in the instantiations of Gen_Pack2 and Gen_Pack3: procedure main is package pack1 is new gen_pack1; use pack1; package pack4 is new gen_pack4 (Pack1.Pack2, Pack1.Pack3); use pack4; ^^^^^^^^^^^^^^^^^^^^^^^^^^ blah blha begin blah end main; > says that expected type is pack2.(type) but found > type is pack21.(type). same for the other package. > i even tried using the same names (stupid maybe) but to no avail. > how can i get out of this? or is this a major design flaw? Not "major"; just a misunderstanding of what an instantiation means. -- The new standards [for science curricula in Kansas] do not forbid the teaching of evolution, but the subject will no longer be included in statewide tests for evaluating students--a virtual guarantee, given the realities of education, that this central concept of biology will be diluted or eliminated, thus reducing courses to something like chemistry without the periodic table, or American history without Lincoln. Stephen Jay Gould, Time, 23 Aug 1999 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney @ 1999-11-17 0:00 ` Mats Weber 1999-11-17 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Riyaz Mansoor 1999-11-19 0:00 ` Robert Dewar 2 siblings, 1 reply; 44+ messages in thread From: Mats Weber @ 1999-11-17 0:00 UTC (permalink / raw) Matthew Heaney wrote: > You should always elaborate packages that you instantiate: > > pragma Elaborate (Gen_Pack1); > pragma Elaborate (Gen_Pack4); Use Elaborate_All: that way, if Gen_Pack* instantiates something else, then that also gets elaborated. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Mats Weber @ 1999-11-17 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Matthew Heaney @ 1999-11-17 0:00 UTC (permalink / raw) In article <3832E75D.5B1BA719@mail.com> , Mats Weber <matsw@mail.com> wrote: >> You should always elaborate packages that you instantiate: >> >> pragma Elaborate (Gen_Pack1); >> pragma Elaborate (Gen_Pack4); > > Use Elaborate_All: that way, if Gen_Pack* instantiates something else, > then that also gets elaborated. I didn't think Elaborate vs Elaborate_All made any difference for generics. From Cohen's AAASL, p682: (start of quote) In all other cases, however, a with clause for a library generic unit should be accompanied by an Elaborate pragma for that unit... An Elaborate_All pragma can be used instead of an Elaborate pragma, but this is not really necessary because the elaboration of a generic body never gives rise to a subprogram call. (end of quote) -- Science is, foremost, a method of interrogating reality: proposing hypotheses that seem true and then testing them -- trying, almost perversely, to negate them, elevating only the handful that survive to the status of a theory. Creationism is a doctrine, whose adherents are interested only in seeking out data that support it. George Johnson, NY Times, 15 Aug 1999 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney @ 1999-11-18 0:00 ` Robert A Duff 1999-11-18 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Mats Weber 1999-11-19 0:00 ` Robert Dewar 2 siblings, 1 reply; 44+ messages in thread From: Robert A Duff @ 1999-11-18 0:00 UTC (permalink / raw) "Matthew Heaney" <matthew_heaney@acm.org> writes: > I didn't think Elaborate vs Elaborate_All made any difference for > generics. From Cohen's AAASL, p682: > > (start of quote) > In all other cases, however, a with clause for a library generic unit > should be accompanied by an Elaborate pragma for that unit... > > An Elaborate_All pragma can be used instead of an Elaborate pragma, but > this is not really necessary because the elaboration of a generic body > never gives rise to a subprogram call. > (end of quote) But elaboration of the *instance* can call something that might cause trouble. And, as somebody else pointed out, you can have nested instantiations. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-18 0:00 ` Robert A Duff @ 1999-11-18 0:00 ` Matthew Heaney 0 siblings, 0 replies; 44+ messages in thread From: Matthew Heaney @ 1999-11-18 0:00 UTC (permalink / raw) In article <wcc1z9nzzsz.fsf@world.std.com> , Robert A Duff <bobduff@world.std.com> wrote: > But elaboration of the *instance* can call something that might cause > trouble. But isn't the generic unit responsible for using the proper pragmas, if it does something in the begin part of its body? (And even if it doesn't have a begin part, it still needs to pragma Elaborate the with'd unit, right?) with GP; pragma Elaborate; package body GQ is package P is new GP; begin P.Do_Something; end GQ; Are you saying that Elaborate is not sufficient here? (That we need an Elaborate_All?) Is the statement in Norm's book correct, or incorrect? > And, as somebody else pointed out, you can have nested > instantiations. But isn't the generic supposed to pragma elaborate the nested generic? -- Creationists attempt to draw a line between evolutionary biology and the rest of science by remarking that large-scale evolution cannot be observed. This tactic fails. Large-scale evolution is no more inaccessible to observation than nuclear reactions or the molecular composition of water. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Robert A Duff @ 1999-11-18 0:00 ` Mats Weber 1999-11-18 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Robert Dewar 2 siblings, 1 reply; 44+ messages in thread From: Mats Weber @ 1999-11-18 0:00 UTC (permalink / raw) Matthew Heaney wrote: > I didn't think Elaborate vs Elaborate_All made any difference for > generics. From Cohen's AAASL, p682: It does: if the generic instantiates another generic, e.g. generic package P1 is ... generic package P2 is ... with P1; package body P2 is package P1I is new P1; end P2; The clause with P2; pragma Elaborate(P2); does not guarantee that P1's body gets elaborated. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-18 0:00 ` Mats Weber @ 1999-11-18 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Mats Weber 0 siblings, 1 reply; 44+ messages in thread From: Matthew Heaney @ 1999-11-18 0:00 UTC (permalink / raw) In article <3833F615.5AD7166C@mail.com> , Mats Weber <matsw@mail.com> wrote: > It does: if the generic instantiates another generic, e.g. > > generic package P1 is ... > > generic package P2 is ... > > with P1; > package body P2 is > package P1I is new P1; > end P2; But isn't this wrong? Shouldn't P2 elaborate P1? with P1; pragma Elaborate (P1); package body P2 is package P1I is new P1; end P2; > > The clause > > with P2; > pragma Elaborate(P2); > > does not guarantee that P1's body gets elaborated. Is this still true if P2 does the proper thing, and elaborates P1? -- Help keep evolution in the science classroom and religion out: become a member of the National Center for Science Education. <http://www.natcenscied.org/> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-18 0:00 ` Matthew Heaney @ 1999-11-19 0:00 ` Mats Weber 1999-11-19 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 44+ messages in thread From: Mats Weber @ 1999-11-19 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > In article <3833F615.5AD7166C@mail.com> , Mats Weber <matsw@mail.com> > wrote: > > > It does: if the generic instantiates another generic, e.g. > > > > generic package P1 is ... > > > > generic package P2 is ... > > > > with P1; > > package body P2 is > > package P1I is new P1; > > end P2; > > But isn't this wrong? Shouldn't P2 elaborate P1? > > with P1; > pragma Elaborate (P1); > > package body P2 is > package P1I is new P1; > end P2; Suppose someone else wrote P2 or is still developping it, and that person does not use pragma Elaborate. With Elaborate_All, you are safe. > > The clause > > > > with P2; > > pragma Elaborate(P2); > > > > does not guarantee that P1's body gets elaborated. > > Is this still true if P2 does the proper thing, and elaborates P1? No. I totally agree with Robert Dewar here: never use Elaborate, use Elaborate_All instead. Your approach of using Elaborate at each level, besides being hard to enforce on a large project, puts unnecessary constraints on the elaboration order: in our example, where P2I instantiates P2 instantiates P1, valid elaboration orders are: P1, P2, P2I and P2, P1, P2I. You are unnecessarily enforcing the first one with your approach. I have done an extensive study of the shortcomings of pragma Elaborate in my thesis at http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Mats Weber @ 1999-11-19 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Mats Weber 1999-11-19 0:00 ` Vladimir Olensky 1 sibling, 2 replies; 44+ messages in thread From: Matthew Heaney @ 1999-11-19 0:00 UTC (permalink / raw) In article <383510EA.9DFEE8B6@mail.com> , Mats Weber <matsw@mail.com> wrote: > No. I totally agree with Robert Dewar here: never use Elaborate, use > Elaborate_All instead. OK, I'm convinced. Never use pragma Elaborate; always use pragma Elaborate_All. Either Norm's book is wrong, or I misinterpreted what he said (probably the latter). > Your approach of using Elaborate at each level, besides being hard to > enforce on a large project, puts unnecessary constraints on the > elaboration order: in our example, where P2I instantiates P2 > instantiates P1, valid elaboration orders are: P1, P2, P2I and P2, P1, > P2I. You are unnecessarily enforcing the first one with your approach. I just assumed that whenever you instantiate a package (inside another package), that you have to pragma Elaborate_All the generic unit. But you seem to advocate only a conditional application of this guideline. When specifically do you recommend using Elaborate_All, versus not needing to bother? -- It is impossible to feel great confidence in a negative theory which has always rested its main support on the weak points of its opponent. Joseph Needham, "A Mechanistic Criticism of Vitalism" ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Matthew Heaney @ 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Robert I. Eachus 1999-11-19 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Mats Weber 1 sibling, 2 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) In article <383569db_2@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > But you seem to advocate only a conditional application of > this guideline. When specifically do you recommend using > Elaborate_All, versus not needing to bother? It's really a rule rather than a guideline, at least for new code, although GNAT will indeed provide the necessary implicit Elaborate_All statements if you leave them out! The rule is simple, if you instantiate a generic from within elaboration code, then you must use a pragma Elaborate_All on the generic. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Robert Dewar @ 1999-11-19 0:00 ` Robert I. Eachus 1999-11-22 0:00 ` Robert Dewar 1999-11-19 0:00 ` Matthew Heaney 1 sibling, 1 reply; 44+ messages in thread From: Robert I. Eachus @ 1999-11-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > It's really a rule rather than a guideline, at least for new > code, although GNAT will indeed provide the necessary implicit > Elaborate_All statements if you leave them out! > > The rule is simple, if you instantiate a generic from within > elaboration code, then you must use a pragma Elaborate_All > on the generic. There are very special cases where you should use Elaborate instead of Elaborate_All, and I occasionally run into them when creating mutually recursive types. But in general use Elaborate_All unless you know when not to. ;-) These cases can occur with generics, but that is very rare. (Two generic units can not directly have mutually dependent bodies, but they can an indirect dependence through other units where the body of C must be elborated after A and after B, where A and B are the generics.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Robert I. Eachus @ 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Matthew Heaney 0 siblings, 1 reply; 44+ messages in thread From: Robert Dewar @ 1999-11-22 0:00 UTC (permalink / raw) In article <3835CF6B.C78469E@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > Robert Dewar wrote: > There are very special cases where you should use Elaborate instead of Elaborate_All, and I occasionally run into them when creating mutually recursive types. Whenever you use Elaborate instead of Elaborate_All, you are counting on (illicit) knowledge of what is in the package body. The above statement is equivalent to a special case of: "there are very special cases where the client must know details of the coding in the package body, ...." Perhaps, but this is always undesirable, so if you can find another way of solving the problem you should. In all our experience with (millions and millions of lines) of Ada code, the only legitimate case for using Elaborate that has cropped up is when compiling old legacy Ada 83 code. Note that in default mode, GNAT supplies the recommended Elaborate_All pragmas implicitly, and it is very rare that new Ada 95 code runs into trouble with this rule (the most common case is where tasks are started at elaboration time). In no cases has the solution been to use pragma Elaborate. The reason that Robert Dewar strongly argued to keep Elaborate in the language as a first class citizen was a) one can construct cases in which it is the only way of doing things, so from a formal point of view, eliminating it would subset the language. b) more pragmatically, people HAVE constructed such cases pretty frequently, usually by accident, in Ada 83 legacy code :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert Dewar @ 1999-11-22 0:00 ` Matthew Heaney 0 siblings, 0 replies; 44+ messages in thread From: Matthew Heaney @ 1999-11-22 0:00 UTC (permalink / raw) In article <81bqg4$55t$1@nnrp1.deja.com> , Robert Dewar <robert_dewar@my-deja.com> wrote: > Note that in default mode, GNAT supplies the recommended > Elaborate_All pragmas implicitly, and it is very rare that > new Ada 95 code runs into trouble with this rule (the most > common case is where tasks are started at elaboration time). > In no cases has the solution been to use pragma Elaborate. For tasks that are started at elaboration time, what is the intended solution? To use the elaborate_all pragma on the packages called by the task? Or is there some other solution? -- Evolution is as well documented as any phenomenon in science, as strongly as the earth's revolution around the sun rather than vice versa. Stephen Jay Gould, Time, 23 Aug 1999 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Robert I. Eachus @ 1999-11-19 0:00 ` Matthew Heaney 1999-11-20 0:00 ` Mats Weber 1 sibling, 1 reply; 44+ messages in thread From: Matthew Heaney @ 1999-11-19 0:00 UTC (permalink / raw) In article <81449o$1fh$1@nnrp1.deja.com> , Robert Dewar <robert_dewar@my-deja.com> wrote: > The rule is simple, if you instantiate a generic from within > elaboration code, then you must use a pragma Elaborate_All > on the generic. But Mats seems to be saying that if you do this: generic ... package GQ is ... end GQ; with GP; package body GQ is package P is new GP; ... end GQ; then you should NOT use an elaborate(_all) pragma on GP. This would appear to be in violation of the rule that you're advocating. So which is it: should the body of GQ above pragma Elaborate_All (GP), or not? -- Get the FAQs about evolution and creationism. <http://www.talkorigins.org/origins/faqs.html> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Matthew Heaney @ 1999-11-20 0:00 ` Mats Weber 0 siblings, 0 replies; 44+ messages in thread From: Mats Weber @ 1999-11-20 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > In article <81449o$1fh$1@nnrp1.deja.com> , Robert Dewar > <robert_dewar@my-deja.com> wrote: > > > The rule is simple, if you instantiate a generic from within > > elaboration code, then you must use a pragma Elaborate_All > > on the generic. > > But Mats seems to be saying that if you do this: > > generic > ... > package GQ is ... end GQ; > > with GP; > package body GQ is > package P is new GP; > ... > end GQ; > > then you should NOT use an elaborate(_all) pragma on GP. This would > appear to be in violation of the rule that you're advocating. No. The above is in a generic body, whose elaboration does nothing: the actual instantiation of GP is going to happen only when GQ is instantiated. If GQ were not generic, then you would need the pragma. GP's body will need to be elaborated before any non-generic unit that instantiates GQ, and that's the only constraint. In particular, it can be elaborated after GQ's body, and that's because GQ is a generic. The elaboration of a generic body has no other effect than to establish that from now on, the generic can be elaborated. Check the RM for details. > So which is it: should the body of GQ above pragma Elaborate_All (GP), > or not? no pragma is necessary. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Robert Dewar @ 1999-11-19 0:00 ` Mats Weber 1999-11-22 0:00 ` Robert Dewar 1 sibling, 1 reply; 44+ messages in thread From: Mats Weber @ 1999-11-19 0:00 UTC (permalink / raw) Matthew Heaney wrote: > I just assumed that whenever you instantiate a package (inside another > package), that you have to pragma Elaborate_All the generic unit. > > But you seem to advocate only a conditional application of this > guideline. When specifically do you recommend using Elaborate_All, > versus not needing to bother? Actually, I have used pragma Elaborate(_All) maybe three times since 1983. I have always let the compiler figure out an elaboration order, which turned out to be just fine in almost all cases with DEC Ada, Verdix and GNAT. I know this approach is not striclty portable, but I don't care and I still think that some minimal automatic elaboration order generation should be in the language standard (see my thesis). ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Mats Weber @ 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Robert A Duff ` (3 more replies) 0 siblings, 4 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-22 0:00 UTC (permalink / raw) In article <3835CF7A.5604C6A3@mail.com>, Mats Weber <matsw@mail.com> wrote: > Actually, I have used pragma Elaborate(_All) maybe three times > since 1983. I have always let the compiler figure out an > elaboration order, which turned out to be just fine in almost > all cases with DEC Ada, Verdix and GNAT. I know this approach > is not striclty portable, but I don't care. Well this is a bit like people not caring about seat belts in a car till they have a crash. We have lots of cases of legacy code, particularly Verdix code, where the programmers were, quite unknowingly relying on non-portable behavior. It is very bad programming practice to omit the pragmas (*). In one hard, we had one customer with a large code who spent quite a bit of time running the program and finding out one bug after another of omitted pragma Elaborate's causing Program_Error. The problem is not that VADS is better at finding an elaboration order than GNAT or vice versa, just that they guess differently in situations where there is no one right way of doing things. You can construct cases where GNAT (**) will succeed where Verdix will fail and vice versa. So Mats may have been lucky programming without an Elaborate seat belt so far, but I do not recommend this risky behavior for others! I have seen far too much grief caused by this viewpoint. > and I still think that some minimal automatic elaboration > order generation should be in the language standard (see my > thesis). The story here is that basically we all agreed, but we also agreed that trying to do this in a reasonably upwards compatible manner was far from easy, and there simply was not enough time available in the course of the Ada 95 design. I definitely agree with Mats in general terms, though I do NOT agree with approaches which require building a call tree and tracing actual execution paths through package bodies. Our experience is that the static elaboration approach in GNAT (which was a very large development effort, which is ongoing as we find new aspects, most recently the issue of task bodies for tasks started at elaboration time) works remarkably well, and it is basically simply an automation of the rules about using pragma Elaborate_All. If you ever had to port a GNAT program to another compiler which provided only the old style dynamic elaboration checks, then you could use -gnatwl to tell you where to put the missing pragma Elaborate_All statements. So generally the GNAT implementation attempts precisely to let people program in the way Mats recomends (don't bother about elaboration), and be sure of not running into trouble. Basically, it is a collision avoidance strategy that makes sure you don't need seatbelts :-) (*) It is actually safe to omit the pragmas when using GNAT in its static default elaboration mode, as noted above. (**) This is referring to GNAT running in -gnatE mode which replicates the traditional dynamic elaboration mode. We have to use the -gnatE mode for validation to get through one test whose comments make it clear that it was written (in some sense in horrible style) precisely to undermine any attempts to find an order of elaboration statically :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert Dewar @ 1999-11-22 0:00 ` Robert A Duff 1999-11-23 0:00 ` Robert Dewar 1999-11-22 0:00 ` Mats Weber ` (2 subsequent siblings) 3 siblings, 1 reply; 44+ messages in thread From: Robert A Duff @ 1999-11-22 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > We have lots of cases of legacy code, particularly Verdix code, > where the programmers were, quite unknowingly relying on > non-portable behavior. It is very bad programming practice > to omit the pragmas (*). But without some help from the compiler, it's quite difficult to get them right. >... In one hard, we had one customer > with a large code who spent quite a bit of time running the > program and finding out one bug after another of omitted pragma > Elaborate's causing Program_Error. And maybe some of those Program_Errors happen inside tasks, where the default behavior is to silently kill the offending task? :-( > The story here is that basically we all agreed, but we also > agreed that trying to do this in a reasonably upwards compatible > manner was far from easy, and there simply was not enough time > available in the course of the Ada 95 design. I've thought about the problem a lot since 1995, and I have yet to come up with an upward compatible solution that is also "good" in all the other respects I'd like. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert A Duff @ 1999-11-23 0:00 ` Robert Dewar 1999-11-29 0:00 ` Robert A Duff 1999-12-01 0:00 ` Robert A Duff 0 siblings, 2 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-23 0:00 UTC (permalink / raw) In article <wcczow6flxa.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I've thought about the problem a lot since 1995, and I have > yet to come up with an upward compatible solution that is also > "good" in all the other respects I'd like. What don't you like about the GNAT scheme, it seems to work remarkably well in practice. There is of course no fully upwards compatible solution (there are halting problem issues), but so what? Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-23 0:00 ` Robert Dewar @ 1999-11-29 0:00 ` Robert A Duff 1999-12-01 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert A Duff 1 sibling, 1 reply; 44+ messages in thread From: Robert A Duff @ 1999-11-29 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <wcczow6flxa.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > I've thought about the problem a lot since 1995, and I have > > yet to come up with an upward compatible solution that is also > > "good" in all the other respects I'd like. > > What don't you like about the GNAT scheme, it seems to work > remarkably well in practice. There is of course no fully > upwards compatible solution (there are halting problem issues), > but so what? "So what?" you say?! The Upward Compatibility Police would have jailed us, and thrown away the key, if we had proposed the current method GNAT uses by default, as the Ada 9X standard way! ;-) The GNAT-default is pretty good, but it's not upward compatible. My statement was that I don't know how to do it "right", and still remain compatible with Ada 83 -- so the GNAT-default method doesn't contradict that, even if it were perfect in every other regard. The GNAT-default method also doesn't meet all of my goals. One example is: All elaboration checks should be done at compile time, or at link time. No run-time checks. The GNAT-default method fails to achieve this for dispatching calls. Since the compiler cannot usually tell where a class-wide object came from, and whether a given call might happen at elaboration time, pretty-much every dispatching call needs a run-time check. I think I know how to solve this problem, but not in a way that is compatible with Ada -- I would need to change the syntax and semantics too much. The same issue applies to access-to-subprogram types. Another goal is portability: I don't like the fact that elaboration order is nondeterministic. This offers no benefit to the user, and causes trouble during porting, when the original programmers have long since been run over by trucks. I'm not sure how the GNAT-default method relates to this -- is it specified to be deterministic? Certainly it *could* be -- just look at the code, and write down whatever arbitrary choices it makes. ---------------------------------------------------------------- By the way, Robert has stated that the GNAT-default method works fine for all but one of the ACVC tests. But that's not nearly as impressive as it might seem. The vast majority of ACVC tests are very simple with respect to elaboration. In particular, they have a single main procedure (which, like any procedure, doesn't call anything at elaboration time), plus the Report package, which doesn't do anything much interesting at elaboration time. The first call to the Report package comes after all library units have been elaborated. (ACVC's also include predefined stuff like Text_IO, but that's irrelevant here -- it's the implementer's responsibility to make Text_IO work at elaboration time, using whatever magic is necessary.) In fact, the Report package has a design flaw -- it doesn't even work properly if you call it at elaboration time. So the ACVC isn't interesting. What's interesting is real programs with hundreds (or more) of library packages, all trying to initialize themselves at elaboration time in the most natural way. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-29 0:00 ` Robert A Duff @ 1999-12-01 0:00 ` Robert Dewar 0 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-01 0:00 UTC (permalink / raw) In article <wccvh6l3wva.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > So the ACVC isn't interesting. What's interesting is real programs with > hundreds (or more) of library packages, all trying to initialize > themselves at elaboration time in the most natural way. As you know, the GNAT static model is the default model. The GNAT approach is in practice upwards compatible with the RM, in that you can always change from this default model to the dynamic model if you want. What this means, making it the default, is that people naturally use the static model until they run into trouble. So far, with almost no exceptions (maybe none, but I hate to say none without a very careful check), the only people who have run into trouble are those porting large Ada 83 codes where in many cases the elaboration is a huge mess. In about half these cases, people have decided to clean things up so that the static model can be used, on the grounds that it is better to eliminate problems in the future. In the other half of cases, people use -gnatE and go to the dynamic model. But for new code, people seem to have no trouble with the static model, and get themselves into FAR less trouble. In fact I think the mistake in the Ada 95 design process was trying to do too much in the elaboration area, and consequently ending up doing nothing (well we have elaborate_all, but I mean nothing in terms of making the model more static). I think it would have been a good idea to bless something like the GNAT static model, which after all simply corresponds to good coding practices in the first place. The elaboration order is of course deterministic in GNAT. However we don't think any programs should depend on the knowledge of the order, so we don't document the determinisitc algorithm. Robert Dewar Ada Core Technologiesb Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-23 0:00 ` Robert Dewar 1999-11-29 0:00 ` Robert A Duff @ 1999-12-01 0:00 ` Robert A Duff 1999-12-02 0:00 ` Mats Weber 1 sibling, 1 reply; 44+ messages in thread From: Robert A Duff @ 1999-12-01 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > What don't you like about the GNAT scheme, it seems to work > remarkably well in practice. There is of course no fully > upwards compatible solution (there are halting problem issues), > but so what? I'm not so worried about the case that involve halting problem issues. That would be an example like: Package body A says (in elaboration code): if <some expression> then B.Do_Something; end if; And package body B says (also in elaboration code): if <some expression> then A.Do_Something; end if; I would be perfectly happy to make examples like that illegal at link time. I'm more concerned about a case where two packages 'with' each other, like the example above, but remove one of those if statements, so it is provable at link time that only one calls the other during elaboration. (Also, the Do_Something procedure had better not call back to the other package.) Making *that* example illegal is my concern. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-01 0:00 ` Robert A Duff @ 1999-12-02 0:00 ` Mats Weber 1999-12-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 44+ messages in thread From: Mats Weber @ 1999-12-02 0:00 UTC (permalink / raw) > I would be perfectly happy to make examples like that illegal at > link time. > > I'm more concerned about a case where two packages 'with' each other, > like the example above, but remove one of those if statements, so it is > provable at link time that only one calls the other during elaboration. > (Also, the Do_Something procedure had better not call back to the other > package.) Making *that* example illegal is my concern. That is just what I did in my thesis. See http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html#RTFToC101 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-02 0:00 ` Mats Weber @ 1999-12-03 0:00 ` Robert Dewar 1999-12-03 0:00 ` Robert A Duff 1999-12-03 0:00 ` Ted Dennison 0 siblings, 2 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-03 0:00 UTC (permalink / raw) In article <38464A8F.FDE762F9@mail.com>, Mats Weber <matsw@mail.com> wrote: > That is just what I did in my thesis There are a number of other explorations of this idea (basically the idea of tracing all possible static flows through a program). In particular, there was an exploration of this idea during the Ada 83 design, and if I remember, a corresponding LSN, and also more recently some work at Binghamton and a published paper. The difficulty is that it is probably not practical to mandate this kind of program wide analysis as a standard feature of all compilers. The GNAT approach, by contrast, can be simply done on a unit by unit basis (static tracing occurs only within a unit), and the approach for inter-unit analysis corresponds in a simple manner to good Ada coding practice (the fundamental principle that a client of a package should rely only on the spec, and not on detailed knowledge of the structure or code of the body). The trouble with this general tracing schemes is that they can still leave you in a situation where your program compiles and runs, and then you change something in a body, and the program no longer compiles because some client somewhere was making elaboration related assumptions about the contents of this body. Of course a compiler that did the full tracing would do a much better job in the fully dynamic case of finding a workable elaboration order, but that's a mixed blessing. The trouble is that if the compiler finds this order for you, then your program may be seriously non-portable and you don't realize it (until you try to port to another system). In fact in GNAT we provide the -p (pessimistic elaboration order) option for the binder. This option is relevant only if you are using fully dynamic elaboration (compiling with the -gnatE switch), and it causes the binder to choose what it thinks is the WORST possible elaboration order, to help smoke out such lurking bugs :-) Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-03 0:00 ` Robert Dewar @ 1999-12-03 0:00 ` Robert A Duff 1999-12-06 0:00 ` Robert Dewar 1999-12-03 0:00 ` Ted Dennison 1 sibling, 1 reply; 44+ messages in thread From: Robert A Duff @ 1999-12-03 0:00 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > The difficulty is that it is probably not practical to mandate > this kind of program wide analysis as a standard feature of > all compilers. I agree that the full program-wide analysis is a bad idea, for all the reasons you stated. What do you think of this compromise: Do the call-graph analysis within each package at compile time, except do the call-graph analysis for each cycle at link time. (The compiler would have to know about the cycles somehow.) The point is that cycles are inherently tightly coupled anyway, so it's not such a horrible thing for two packages to know about each others' bodies. The other point is that cycles are not common, and are usually small (length 2, often), so the link-time efficiency problem is probably not so bad. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-03 0:00 ` Robert A Duff @ 1999-12-06 0:00 ` Robert Dewar 0 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-06 0:00 UTC (permalink / raw) In article <wccln7cc9dw.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > The other point is that cycles are not common, and are > usually small (length 2, often), so the link-time efficiency > problem is probably > not so bad. That's still a huge amount of information that has to be passed from the compiler to the linker (to enable it to do full call graph analysis) I don't see it as practical to mandate this. After all, the GNAT approach just corresponds to good programming practice (clearly calling something from a package at elaboration time without using Elaborate_All is plain bad coding practice!) In practice, I don't think anyone has found the static scheme a big burden except in Ada 83 legacy code. We don't know of anyone using the dynamic approach *except* in the Ada 83 legacy code case. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-03 0:00 ` Robert Dewar 1999-12-03 0:00 ` Robert A Duff @ 1999-12-03 0:00 ` Ted Dennison 1999-12-04 0:00 ` Robert Dewar 1 sibling, 1 reply; 44+ messages in thread From: Ted Dennison @ 1999-12-03 0:00 UTC (permalink / raw) In article <828mu3$8i0$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> wrote: > you try to port to another system). In fact in GNAT we provide > the -p (pessimistic elaboration order) option for the binder. > This option is relevant only if you are using fully dynamic > elaboration (compiling with the -gnatE switch), and it causes > the binder to choose what it thinks is the WORST possible > elaboration order, to help smoke out such lurking bugs :-) Interesting. Have you given any thought to doing this for other implemetation-defined things, like ordering of record fields and caching of global data? -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-03 0:00 ` Ted Dennison @ 1999-12-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-04 0:00 UTC (permalink / raw) In article <828nuu$95s$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Interesting. Have you given any thought to doing this for > other implemetation-defined things, like ordering of record > fields and caching of global data? No, because that does not serve the purpose of writing reliable programs using GNAT. In the case of elaboration order, if you are using -gnatE, you really want to make sure that all the necessary pragma Elaborate_All statements are in place, since otherwise your program can run into maintenance problems when changes are made. However, in the case of ordering of record fields, we guarantee that there is no reordering in GNAT, so that is not a source of unreliability. It might be useful if you are using GNAT to develop programs that are intended to port to other Ada compilers, but our primary goal is to provide the features to write reliable programs using GNAT, so this is definitely a secondary low priority goal. We do give warnings in cases where the code has clearly undesirable implementation dependent properties that might change in future releases. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Robert A Duff @ 1999-11-22 0:00 ` Mats Weber 1999-11-22 0:00 ` Robert A Duff 1999-11-22 0:00 ` Larry Kilgallen 1999-11-22 0:00 ` Mats Weber 3 siblings, 1 reply; 44+ messages in thread From: Mats Weber @ 1999-11-22 0:00 UTC (permalink / raw) Robert Dewar wrote: > So Mats may have been lucky programming without an Elaborate > seat belt so far, but I do not recommend this risky behavior > for others! I have seen far too much grief caused by this > viewpoint. BTW, I don't think I was just lucky: the elaboration order control was supposed to be automatic in Ada 80, which of course is not feasible. I think DEC Ada, and maybe Verdix, went quite some way in the Ada 80 direction before the '83 standard was accepted, so pragma Elaborate was rarely necessary. Just a suppostion. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Mats Weber @ 1999-11-22 0:00 ` Robert A Duff 1999-11-23 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 44+ messages in thread From: Robert A Duff @ 1999-11-22 0:00 UTC (permalink / raw) Mats Weber <matsw@mail.com> writes: > BTW, I don't think I was just lucky: the elaboration order control was > supposed to be automatic in Ada 80, which of course is not feasible. I think it *is* feasible. In fact, the latest GNAT does determine an order automatically -- and if it can't, it complains at link time. This is just like any other compile-time or link-time rule -- the halting problem tells us we have to make the rules somewhat conservative compared to corresonding run-time rules -- but that *is* feasible in many cases. I certainly don't believe the designers of Ada 83 (in 1980) thought it's possible for compiler to solve the halting problem. I think they just wrote the rule in a slightly sloppy way. They could have rewritten it to say what they always meant, but instead they chose to go with run-time checking -- I presume because that makes things simpler by avoiding a link-time analysis of the entire program's call graph. - Bob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert A Duff @ 1999-11-23 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-23 0:00 UTC (permalink / raw) In article <wccyabqfldi.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > They could have rewritten it > to say what they always meant, but instead they chose to go with > run-time checking -- I presume because that makes things simpler by > avoiding a link-time analysis of the entire program's call graph. That's not my memory! I think what happened was that there was a realization that given the fundamental elaboration semantics that had been agreed on, there WAS no static solution. If I remember right, it was Bryce who came up with the worrisome examples, but that's a long time ago :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert A Duff 1999-11-23 0:00 ` Robert Dewar @ 1999-12-01 0:00 ` Robert I. Eachus 1999-12-01 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 44+ messages in thread From: Robert I. Eachus @ 1999-12-01 0:00 UTC (permalink / raw) Robert A Duff wrote: > I certainly don't believe the designers of Ada 83 (in 1980) thought it's > possible for compiler to solve the halting problem. I think they just > wrote the rule in a slightly sloppy way. They could have rewritten it > to say what they always meant, but instead they chose to go with > run-time checking -- I presume because that makes things simpler by > avoiding a link-time analysis of the entire program's call graph. I don't think so. We started building SLANG as a subset of Ada 80. It later grew to be a pretty large subset of Ada 83 (and changed it's name to Ada/SIL). This compiler had a rather agressive optimizer that created and heavily used the call graph. For example it would combine the stack frames for non-recursive subprograms with the parent, which required some pretty sophisticated static analysis. After Ada82 was published, it would also eliminate the "elaborated" bit, and any checks for it in any unit that could be statically shown not to be called before elaboration. I argued fairly strongly for making elaboration checks dynamic based on what we found when trying to implement the Ada 80 rules. Most small programs were easy to find an elaboration order for and (later) eliminate all elaboration checks. But larger programs would hit a complexity barrier where finding a static elaboration order--if one existed--took longer than compiling all of the compilation units. Putting elaboration bits in just a few packages dramatically decreased link times. There were three packages that got hit all the time, but I'll give one example: Good belt and suspenders programming practice is to include in exception handling code a quick message to tell what went wrong. Some of these stay in the delivered version, some are inserted during debugging and taken out during integration along with many others. Of course, changing these messages could change the elaboration order for the program, or worse, create a situation where no workable elaboration order existed. If this check was static, there was no way to find and remove this emergent property of the program other than to backtrack. This was no help to the guy trying to get the initialization code of a large system to work. He was MUCH happier getting -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-12-01 0:00 ` Robert I. Eachus @ 1999-12-01 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 44+ messages in thread From: Robert I. Eachus @ 1999-12-01 0:00 UTC (permalink / raw) I wrote: > ...Of course, changing these messages could change the elaboration order > for the program, or worse, create a situation where no workable > elaboration order existed. If this check was static, there was no way > to find and remove this emergent property of the program other than to > backtrack. This was no help to the guy trying to get the initialization > code of a large system to work. He was MUCH happier getting And accidentally hit the send button. (It is the one thing I hate about Netscape Communicator. The Send button is too near the File and Edit menus.) In any case: He (or she) was much happier getting the first part of the elaboration code debugged, then recompiling and getting incrementally further. This could leave many error messages that would raise Program_Error if invoked, but so what, it still got you to the location of the real error, often with a Text_IO call that had the correct message text as a parameter. ;-) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Robert A Duff 1999-11-22 0:00 ` Mats Weber @ 1999-11-22 0:00 ` Larry Kilgallen 1999-11-23 0:00 ` Robert Dewar 1999-11-22 0:00 ` Mats Weber 3 siblings, 1 reply; 44+ messages in thread From: Larry Kilgallen @ 1999-11-22 0:00 UTC (permalink / raw) In article <81bt4v$7cr$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <3835CF7A.5604C6A3@mail.com>, > Mats Weber <matsw@mail.com> wrote: > >> Actually, I have used pragma Elaborate(_All) maybe three times >> since 1983. I have always let the compiler figure out an >> elaboration order, which turned out to be just fine in almost >> all cases with DEC Ada, Verdix and GNAT. I know this approach >> is not striclty portable, but I don't care. > > Well this is a bit like people not caring about seat belts in > a car till they have a crash. No, because this only applies to code that will be ported. Larry Kilgallen ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Larry Kilgallen @ 1999-11-23 0:00 ` Robert Dewar 0 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-23 0:00 UTC (permalink / raw) In article <1999Nov22.163234.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > No, because this only applies to code that will be ported. > > Larry Kilgallen I disagree for several reasons: 1. Being sure that code will not be ported is a bit like the COBOL programmers back in the 60's and 70's being sure that their code would not still be running at Y2K. 2. Even if you are not porting to different systems, new versions of compilers may have differing behaviors. 3. Any maintenance activity may cause worst case elaboration problems to mysteriously appear. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1999-11-22 0:00 ` Larry Kilgallen @ 1999-11-22 0:00 ` Mats Weber 1999-11-22 0:00 ` Bryce Bardin 1999-11-23 0:00 ` Robert Dewar 3 siblings, 2 replies; 44+ messages in thread From: Mats Weber @ 1999-11-22 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <3835CF7A.5604C6A3@mail.com>, > Mats Weber <matsw@mail.com> wrote: > > > Actually, I have used pragma Elaborate(_All) maybe three times > > since 1983. I have always let the compiler figure out an > > elaboration order, which turned out to be just fine in almost > > all cases with DEC Ada, Verdix and GNAT. I know this approach > > is not striclty portable, but I don't care. > > Well this is a bit like people not caring about seat belts in > a car till they have a crash. Well, the crash is not that bad, is it ? The worst thing you can get (provided that no tasks started at elaboration time) is Program_Error at some point before the main procedure is called by the environment task, is that right ? If it is, then I can live with it. And I am not saying that I advocate using my sloppy approach, I was just saying that reasonable compilers do it right on reasonable code. At the time I was writing the code, there was no GNAT to tell me where to put the pragmas, and I don't think it is reasonable to expect programmers to get the pragmas right without a tool helping them, especially in Ada 83 where there was just Elaborate and no Elaborate_All. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Mats Weber @ 1999-11-22 0:00 ` Bryce Bardin 1999-11-23 0:00 ` Robert Dewar 1 sibling, 0 replies; 44+ messages in thread From: Bryce Bardin @ 1999-11-22 0:00 UTC (permalink / raw) Mats Weber wrote: > > Robert Dewar wrote: > > > > In article <3835CF7A.5604C6A3@mail.com>, > > Mats Weber <matsw@mail.com> wrote: > > > > > Actually, I have used pragma Elaborate(_All) maybe three times > > > since 1983. I have always let the compiler figure out an > > > elaboration order, which turned out to be just fine in almost > > > all cases with DEC Ada, Verdix and GNAT. I know this approach > > > is not striclty portable, but I don't care. > > > > Well this is a bit like people not caring about seat belts in > > a car till they have a crash. > > Well, the crash is not that bad, is it ? The worst thing you can get > (provided that no tasks started at elaboration time) is Program_Error at > some point before the main procedure is called by the environment task, > is that right ? If it is, then I can live with it. > It is a bit harder to live with when your multi-million line system keeps crashing in that manner. It takes a while to find, fix, and rebuild. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-22 0:00 ` Mats Weber 1999-11-22 0:00 ` Bryce Bardin @ 1999-11-23 0:00 ` Robert Dewar 1 sibling, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-23 0:00 UTC (permalink / raw) In article <38398127.59E30D26@mail.com>, Mats Weber <matsw@mail.com> wrote: > Well, the crash is not that bad, is it ? The worst thing you > can get provided that no tasks started at elaboration time) is > Program_Error at some point before the main procedure is > called by the environment task, is that right ? If it is, then > I can live with it. The trouble is the *I* here. The real scenario is as follows. A large and complex program is developed without systematic use of these pragmas. In practice you will find a few Elaborate pragmas presumably stuck in to correct problems with a different compiler. Then you port to a new compiler, and you get Program_Error. Finding and fixing these program errors can be quite complex! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-19 0:00 ` Mats Weber 1999-11-19 0:00 ` Matthew Heaney @ 1999-11-19 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 44+ messages in thread From: Vladimir Olensky @ 1999-11-19 0:00 UTC (permalink / raw) Mats Weber wrote in message <383510EA.9DFEE8B6@mail.com>... >I have done an extensive study of the shortcomings of pragma Elaborate >in my thesis at >http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html It is always very interesting to know different proposals and ideas regarding language evolution at different stages. I think that at least one thing from that thesis, namely par. 4.4 "Control of Direct Visibility (use clauses) " still could be applied for next language revisions. I think that construct USE Package_Name.Procedure_Name which is direct equivalent to FROM Module_Name IMPORT Procedure_Name being used in M2 and M3 could be very useful. Another problem at some extent related to elaboration that still need to be solved is circular packages dependencies. This problem is well known as well as different proposals as how to solve this. It is interesting to know whether this issue will be addressed in the next language revision. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Robert A Duff 1999-11-18 0:00 ` Mats Weber @ 1999-11-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) In article <383319e8_4@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > I didn't think Elaborate vs Elaborate_All made any difference > for generics. From Cohen's AAASL, p682: Well I am sure you are misreading Cohen here, because it is obvious that if you do a generic instantiation at elaboration time, the generic instance may do all sorts of function calls during is elaboration. Perhaps you are getting mixed up between a generic package and a generic instantiation. I will repeat, there is NEVER a case where pragma Elaborate is appropriate in Ada 95. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney 1999-11-17 0:00 ` Mats Weber @ 1999-11-18 0:00 ` Riyaz Mansoor 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Robert Dewar 2 siblings, 1 reply; 44+ messages in thread From: Riyaz Mansoor @ 1999-11-18 0:00 UTC (permalink / raw) > That's because these are different instantiations of Gen_Pack2 and > Gen_Pack3. The solution is to have Gen_Pack4 import the instantiations, > instead of making its own: i tried to do the above as u've suggested. just a note i forgot in the previous post. pack4 needs functins in pack2 and pack3 but pack4 can/should be able to manipulate then through pack1. hence the initialisation of pack2 and pack3 from within pack1. > > procedure main is > package pack1 is new gen_pack1; use pack1; > package pack4 is new gen_pack4 (Pack1.Pack2, Pack1.Pack3); use pack4; > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > blah blha > begin > blah > end main; hence i've initialise main as procedure main is package pack1 is new gen_pack1; use pack; package pack4 is new gen_pack4(pack1); use pack4; blah end main; for gen_pack4 > generic > with package Pack2 is new Gen_Pack2 (<>); > with package Pack3 is new Gen_Pack3 (<>); hence pack4 is initialised as generic with package pack1 is new gen_pack1(<>); i believe this is the same as u've suggested. but however it does not compile. it gives an error at the following point in the main. procedure main is package pack1 is new gen_pack1; use pack; package pack4 is new gen_pack4({error here}pack1); use pack4; blah end main; the error message says that "previous error in declaration of formal package" and i dont' know what that means!! any help appreciated thanx riyaz ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-18 0:00 ` Riyaz Mansoor @ 1999-11-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) Boy, this is a confused thread. One suggestion here, read the chapter in the GNAT user's guide on elaboration issues. It has a rather complete discussion along with examples, and may help to make things clearer. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: generic package dilemma 1999-11-17 0:00 ` Matthew Heaney 1999-11-17 0:00 ` Mats Weber 1999-11-18 0:00 ` Riyaz Mansoor @ 1999-11-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) In article <3832e27f_1@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > > -- main procedure > > with gen_pack1; > > with gen_pack4; > > You should always elaborate packages that you instantiate: > > pragma Elaborate (Gen_Pack1); > pragma Elaborate (Gen_Pack4); This is quite incorrect advice in two respects. First: you only need to worry about elaboration if you are doing the instantiation in elaboration code, which is not the case in the example to which you are responding. Second: if (unlike this case) you are doing an instantiation in elaboration code, then *always* use Elaborate_All in Ada 95. The number of cases where Elaborate is appopriate is very small. I actually am the one responsible for the examples that caused pragma Elaborate to be "rescued" from Annex J, but basically it is only poorly written legacy code that needs pragma Elaborate as opposed to Elaborate_All. The simple usage rule is NEVER use pragma Elaborate, ALWYAS use pragma Elaborate_All instead. But to repeat, neither pragma is appropriate in the case where the instantiations occur within a procedure! Either the procedure is called at elaboration time or it is not. If it is not, then there is nothing to worry about. If it is called at elaboration problem, then the burden is on the caller to do an Elaborate_All, which will ensure that the generics are elaborated before they are instantiated. Elaboration stuff is tricky! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~1999-12-06 0:00 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-17 0:00 generic package dilemma Riyaz Mansoor 1999-11-17 0:00 ` Matthew Heaney 1999-11-17 0:00 ` Mats Weber 1999-11-17 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Robert A Duff 1999-11-18 0:00 ` Matthew Heaney 1999-11-18 0:00 ` Mats Weber 1999-11-18 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Mats Weber 1999-11-19 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Robert I. Eachus 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Matthew Heaney 1999-11-19 0:00 ` Matthew Heaney 1999-11-20 0:00 ` Mats Weber 1999-11-19 0:00 ` Mats Weber 1999-11-22 0:00 ` Robert Dewar 1999-11-22 0:00 ` Robert A Duff 1999-11-23 0:00 ` Robert Dewar 1999-11-29 0:00 ` Robert A Duff 1999-12-01 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert A Duff 1999-12-02 0:00 ` Mats Weber 1999-12-03 0:00 ` Robert Dewar 1999-12-03 0:00 ` Robert A Duff 1999-12-06 0:00 ` Robert Dewar 1999-12-03 0:00 ` Ted Dennison 1999-12-04 0:00 ` Robert Dewar 1999-11-22 0:00 ` Mats Weber 1999-11-22 0:00 ` Robert A Duff 1999-11-23 0:00 ` Robert Dewar 1999-12-01 0:00 ` Robert I. Eachus 1999-12-01 0:00 ` Robert I. Eachus 1999-11-22 0:00 ` Larry Kilgallen 1999-11-23 0:00 ` Robert Dewar 1999-11-22 0:00 ` Mats Weber 1999-11-22 0:00 ` Bryce Bardin 1999-11-23 0:00 ` Robert Dewar 1999-11-19 0:00 ` Vladimir Olensky 1999-11-19 0:00 ` Robert Dewar 1999-11-18 0:00 ` Riyaz Mansoor 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox