From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 25 Feb 93 16:05:20 GMT
From: emory!europa.eng.gtefsd.com!howland.reston.ans.net!usc!cs.utexas.edu!uwm.
edu!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!jbg@ga
tech.edu  (John Goodenough)
Subject: Re: compilation order of generic body & instantiation
Message-ID: <1993Feb25.110520.28845@sei.cmu.edu>
List-Id: <comp.lang.ada>

In article <C2o4zF.M7o@taurus.cs.nps.navy.mil>, erickson@cs.nps.navy.mil (David
 Erickson) writes:
|> I ran into a compilation problem that I don't understand: the package below 
|> compiles, but if I attempt to instantiate it in a procedure ("driver"), the 
|> compiler (Meridian Sparc Ada) will produce an error listing at the point of 
|> instantiation.  The error is:
|> "driver.a", 3: identifier not found "binary_tree" [LRM 4.1/3]
|> 
|> If the compilation order is changed (the original order is package spec,
|> body and driver) to spec, driver then body, the compilation produces no
|> errors, but the linking stage produces:
|> bamp: "driver" must be recompiled [LRM 10.3/2]
|> bamp: "driver" has unresolved generic instantiations
|> bamp: the body of "driver" must be compiled [LRM 10.3/2]
|> 
|> I found that if I move the definition of TRAVERSE so that it comes prior 
|> to function PARENT (which includes an instantiation of TRAVERSE), the error 
|> goes away. 
|> 
|> So what is the cause of the problem?  Does Ada require that the body of a 
|> generic procedure come before an instantiation?  Or is this a bug
|> in the Meridian compiler?
|> 
|> I tried compiling the same program using Verdix Ada, and had no problems
|> with either ordering of TRAVERSE and PARENT.
|> 
|> generic
|>   type ATOM is private;
|> package BIN_TREE is
	...
|>   generic
|>     with procedure PROCESS(T: in out BINARY_TREE) is <>;
|>   procedure TRAVERSE(T    : in out BINARY_TREE;
|>                      MODE : TRAVERSAL_TYPE);
	...
|> end BIN_TREE;
|> 
|> package body BIN_TREE is
	...
|>   function PARENT(P, T : BINARY_TREE) return BINARY_TREE is
	...
|>     procedure FIND_PARENT is
|>       new TRAVERSE(PROCESS => TEST_PARENT);
|>   begin       -- PARENT
	...
|>   end PARENT;
|> 
|>   procedure TRAVERSE(T    : in out BINARY_TREE;
|>                      MODE : TRAVERSAL_TYPE) is
	...
|>   begin
	...
|>   end TRAVERSE;
|> end BIN_TREE;
|> 
|> with BIN_TREE;
|> procedure DRIVER is
|>   package MY_TREE is new BIN_TREE(CHARACTER);  -- error occurs here
	...
|> begin
	...
|> end DRIVER;
|> 

First we need to consider whether there are elaboration order problems,
because an instantiation of TRAVERSE occurs textually prior to its body.
Presumably the procedure DRIVER is the main program, so the body of BIN_TREE
will be elaborated before BIN_TREE is instantiated (otherwise, you would need
to put a pragma ELABORATE (BIN_TREE) to ensure BIN_TREE's body is elaborated
in time).  The elaboration of BIN_TREE's body causes the body of TRAVERSE to
be elaborated before the function PARENT is called (since there is no call to
PARENT prior to the elaboration of TRAVERSE), so when PARENT is called the
body of TRAVERSE has been elaborated and the instantiation should proceed
correctly.  My point in discussing elaboration order is that putting the body
of TRAVERSE textually after an instantiation of TRAVERSE always raises the
possibility of elaboration order errors arising, so it's probably not good
style even if it works out this time.

Some implementations require that the body of a generic unit be compiled
before any instantiations of the unit are compiled.  AI-00506 allows such an
assumption for generic units that are compilation units, but does not go so
far as to extend this permission to cases like the above, I think in part
because the ARG didn't consider the above example.  The trend of
thinking at the time of AI-00506's approval was to allow implementations to
make this assumption, so maybe it is too strict to say that Meridian's
compiler is in error on this point.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391