Re: seperate keyword and seperate compilation with Gnat?

[jsa@organon.com (Jon S Anthony)]

In article <4rckva$dj1@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel Mize) writes:

> In article <31D95D93.28D8D15B@jinx.sckans.edu>,
> David Morton  <dmorton@jinx.sckans.edu> wrote:
>......
> >in file foo.adb  (the test file)
> >procedure bar is seperate;
> >
> >then in file foo-bar.adb
> >
> >seperate(foo) (the assignment file)
> >procedure bar is
> >...
> >
> >He argues that the file foo.adb should be able to be compiled,
> >seperately, since the specification is there, even though the actual
> >procedure body has not been written. I'm inclined to believe that
> >he's right,
> 
> He's certainly right (at least for Ada83, and I *think* for Ada95)
> (unless he's actually spelling it "seperate" in the code).
> 
> 
> >but gnat refuses to cleanly compile unless the file foo-bar.adb exists.
> 
> The parent unit should compile (but not link).  Might your gnat set-up
> be automatically trying to link?  (Just a wild guess.)
> 
> Since I haven't seen this mentioned on comp.lang.ada, I assume it
> isn't a problem with gnat itself.

Well, this has always struck me as one of those gray areas in both the
GNAT implementation and the ARM95.  Maybe Tucker or Robert can clear
it up.  The relevant starting point is in 10.1.3 and in particular,
paragraphs 15 & 16:


                Post-Compilation Rules

(15)
       For each body_stub, there shall be a subunit containing the
       corresponding proper_body.

              NOTES
(16)
              (4) The rules in 10.1.4, ``The Compilation Process'' say
              that a body_stub is equivalent to the corresponding
              proper_body. 


So, the _post_ compilation rule of (15) sez for any body_stub (in the
relevant parent body) there exists a cooresponding subunit with the
"actual body" (so called proper_body).  This bit seems to say the
proper_body is _not_ necessary for the compilation to succeed.

(16) goes on to say (oh, btw, what is the significance of the "4"
prefix?) that 10.1.4 sez that the stub is (for the compilation) the
same as the proper_body.  To me this means it is sufficient to get a
successful compilation.  But I suppose it could mean almost anything.
So, (16) would also seem to say you should not get an error for the
compilation of the parent body if the proper_body of the stub did not
exist _at the time_ of the compilation.

So, these bits seem to indicate that GNAT is playing a little loose with
the rules. But -

Just to make the situation completely confusing (maybe even self
contradictory, but it's so confusing a mere mortal such as myself
can't really tell) 10.1.4 has the following things to say:

2)
       The declarative_items of the environment are library_items
       appearing in an order such that there are no forward semantic
       dependences. Each included subunit occurs in place of the
       corresponding stub.
....

(5)
       When a compilation unit is compiled, all compilation units upon
       which it depends semantically shall already exist in the
       environment;

OK, depending on what "forward semantic dependences" or "depends
semantically" mean, this could be saying that to successfully compile
a parent_body a proper_body _does_ need to exist in the environment.
So, off we go hunting to find what these may mean.  The closest I am
able to find on this is in 10.1.1(23-24)(26):


(23)
       There are two kinds of dependences among compilation units: 
(24)
              The semantic dependences (see below) are the ones needed
              to check the compile-time rules across compilation unit
              boundaries; a compilation unit depends semantically on
              the other compilation units needed to determine its
              legality. The visibility rules are based on the semantic
              dependences.

(26)
       A library_item depends semantically upon its parent
       declaration. A subunit depends semantically upon its parent
       body. A library_unit_body depends semantically upon the
       corresponding library_unit_declaration, if any. A compilation
       unit depends semantically upon each library_item mentioned in a
       with_clause of the compilation unit. In addition, if a given
       compilation unit contains an attribute_reference of a type
       defined in another compilation unit, then the given compilation
       unit depends semantically upon the other compilation unit. The
       semantic dependence relationship is transitive. 

To me, these bits don't really nail down the answer.  For one thing,
this does not talk about the "forward" part mentioned in 10.1.4(2) (or
maybe this is meant to be subsumed under the "transitive" bit at the
end of (26)).

The list in (26) seems to be basically irrelevant as it does not
explicitly address the issue of parent_bodies.

(24) first says that semantic dependences are the ones needed to check
compile-time rules across compilation unit boundaries.  Presumably
these are somehow the sum total of all such rules that might apply -
including, perhaps, ones concerning certain implementation
requirements.

(24) then says that a unit "depends semantically" (the
very same term used in 10.1.4(5)) on the other units _needed to
determine its legality_.  In the current context, one reading of this
might be that a parent_body is legal iff the proper_body of each stub
conforms to that stub.  Afterall, they are _from the point of view of
the compilation_ the same thing (back to 10.1.3(16)).  If either of
these cases are "acceptable" readings, GNAT would be perfectly fine in
its behavior on this issue.

I tend to think they aren't and it isn't. But, shrug, I really don't
know...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com