generic package dilemma

generic package dilemma

[Riyaz Mansoor]

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

Re: generic package dilemma

[Matthew Heaney]

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

Re: generic package dilemma

[Mats Weber]

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.

Re: generic package dilemma

[Matthew Heaney]

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

Re: generic package dilemma

[Mats Weber]

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.

Re: generic package dilemma

[Matthew Heaney]

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/>

Re: generic package dilemma

[Mats Weber]

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

Re: generic package dilemma

[Vladimir Olensky]

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

Re: generic package dilemma

[Matthew Heaney]

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"

Re: generic package dilemma

[Mats Weber]

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).

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Mats Weber]

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.

Re: generic package dilemma

[Robert A Duff]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert I. Eachus]

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...

Re: generic package dilemma

[Robert I. Eachus]

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...

Re: generic package dilemma

[Robert A Duff]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert A Duff]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert A Duff]

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

Re: generic package dilemma

[Mats Weber]

> 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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert A Duff]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Ted Dennison]

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.

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Larry Kilgallen]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Mats Weber]

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.

Re: generic package dilemma

[Bryce Bardin]

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.

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Matthew Heaney]

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>

Re: generic package dilemma

[Mats Weber]

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.

Re: generic package dilemma

[Robert I. Eachus]

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...

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Matthew Heaney]

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

Re: generic package dilemma

[Robert A Duff]

"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

Re: generic package dilemma

[Matthew Heaney]

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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Riyaz Mansoor]

> 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

Re: generic package dilemma

[Robert Dewar]

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.

Re: generic package dilemma

[Robert Dewar]

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.