comp.lang.ada
 help / color / mirror / Atom feed
* Elaboration of nested packages.
@ 1997-06-18  0:00 Bill Keen
  1997-06-19  0:00 ` Robert A Duff
  1997-06-20  0:00 ` Robert Dewar
  0 siblings, 2 replies; 5+ messages in thread
From: Bill Keen @ 1997-06-18  0:00 UTC (permalink / raw)



The following piece of code expresses the essence of a problem I am
having in an Ada project using Ada83 and an old Alsys cross compiler. I
brought the fragment home to exercise it using GNAT 3.07 on DOS, and I
am more confused than ever.

with Ada.text_io; use Ada.text_io;
procedure P is
  package OP is
    generic
    package IG is
    end IG;
  end OP;
  package PI is new OP.IG; -- Is this ok?
  package body OP is
    package body IG is
    begin
      put_line("Elaborated body IG");
    end;
  begin
    put_line("Elaborated body OP");
  end;
begin
  put_line("Main program");
end P;

When I run the program it generates I get:
Elaborated body OP
Main program

If I move the instantiation of OP.IG to below the body of OP the result
seems quite logical as it prints:
Elaborated body OP
Elaborated body IG
Main program

The first case baffles me. Does it never instantiate IG? 

The investigation started when I thought in Ada83 this should raise
Program_error because of access before elaboration. I haven't run this
exact example on the Alsys compiler yet, but similar examples compile
and run ok. The LRM(83) 11.1-7 says (of Program_error) "This exception
is raised upon an attempt ... to elaborate a generic instantiation if
the body of the corresponding unit has not been elaborated." Surely the
instantiation of OP.IG qualifies.

I can't find a statement corresponding to 11.1-7 in the Ada95 RM. Has
the meaning of program_error changed in Ada95?

-- 
Bill Keen




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Elaboration of nested packages.
  1997-06-18  0:00 Elaboration of nested packages Bill Keen
@ 1997-06-19  0:00 ` Robert A Duff
  1997-06-20  0:00 ` Robert Dewar
  1 sibling, 0 replies; 5+ messages in thread
From: Robert A Duff @ 1997-06-19  0:00 UTC (permalink / raw)



In article <yrQ8RCAF8EqzEwgc@marnhull.demon.co.uk>,
Bill Keen  <billy@marnhull.demon.co.uk> wrote:
>  package PI is new OP.IG; -- Is this ok?

No.  It should raise P_E (in both Adas 83 and 95).

>I can't find a statement corresponding to 11.1-7 in the Ada95 RM. Has
>the meaning of program_error changed in Ada95?

No.  The rule is cleverly hidden (;-)) in 3.11(13-14).

- Bob




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Elaboration of nested packages.
  1997-06-18  0:00 Elaboration of nested packages Bill Keen
  1997-06-19  0:00 ` Robert A Duff
@ 1997-06-20  0:00 ` Robert Dewar
  1997-06-22  0:00   ` Bill Keen
  1 sibling, 1 reply; 5+ messages in thread
From: Robert Dewar @ 1997-06-20  0:00 UTC (permalink / raw)



Bill Keen asks about

<<with Ada.text_io; use Ada.text_io;
procedure P is
  package OP is
    generic
    package IG is
    end IG;
  end OP;
  package PI is new OP.IG; -- Is this ok?
  package body OP is
    package body IG is
    begin
      put_line("Elaborated body IG");
    end;
  begin
    put_line("Elaborated body OP");
  end;
begin
  put_line("Main program");
end P;>>


This is invalid code, since the instantiation appears before the body of
the generic. It should raise Program_Error, but this check is not in GNAT
3.07.

The current version of GNAT (3.10) will generate a static warning that this
instantiation will raise Program_Error, and then if you execute the program,
it *will* raise program_error.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Elaboration of nested packages.
  1997-06-20  0:00 ` Robert Dewar
@ 1997-06-22  0:00   ` Bill Keen
  1997-06-22  0:00     ` Robert Dewar
  0 siblings, 1 reply; 5+ messages in thread
From: Bill Keen @ 1997-06-22  0:00 UTC (permalink / raw)



In article <dewar.866853665@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>This is invalid code, since the instantiation appears before the body of
>the generic. It should raise Program_Error, 

Thanks, both repsonses have confirmed my understanding. It is just that
the two compilers at work both let this through, Alsys 4.2 and Green
Hills 1.8.7 (I think) and when I brought it home and run it through GNAT
I started to doubt my grasp of the issue. It seems that many compilers
are lax in this area.

The odd thing is, if you declare the generic at the outer level the
Alsys compiler spots the problem right away. 
  ...
  generic
  package IG is
  end IG;
  package PI is new OP.IG; -- Is this ok?
  package body IG is
  begin
  end;
  ...
Hide it in one layer of package and it can't see the problem.

-- 
Bill Keen




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Elaboration of nested packages.
  1997-06-22  0:00   ` Bill Keen
@ 1997-06-22  0:00     ` Robert Dewar
  0 siblings, 0 replies; 5+ messages in thread
From: Robert Dewar @ 1997-06-22  0:00 UTC (permalink / raw)



Bill Keen said (of missing elaboration checks for generic instantiations)

<<Hide it in one layer of package and it can't see the problem.>>

The ACVC tests are surprisingly weak in this area. We encountered some tests
in the DEC test suite (which is much more thorough than the ACVC suite in
some areas) and realized that early versions of GNAT had a big gap in this
checking requirement, and then looked back, and were surprised to find ZERO
tests in the ACVC suite for this.

GNAT 3.10 generates the correct tests in all cases, but it is no surprise
to me that this is a weak area, given the lack of ACVC tests. I do not know
if ACVC suite 2.1 corrects this deficiency or not.

Robert Dewar
Ada Core Technologies





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1997-06-22  0:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-06-18  0:00 Elaboration of nested packages Bill Keen
1997-06-19  0:00 ` Robert A Duff
1997-06-20  0:00 ` Robert Dewar
1997-06-22  0:00   ` Bill Keen
1997-06-22  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