From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a9844368dd0a842 X-Google-Attributes: gid103376,public From: jsa@organon.com (Jon S Anthony) Subject: Re: seperate keyword and seperate compilation with Gnat? Date: 1996/07/04 Message-ID: X-Deja-AN: 163603680 sender: news@organon.com (news) references: <31D95D93.28D8D15B@jinx.sckans.edu> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-07-04T00:00:00+00:00 List-Id: In article <4rckva$dj1@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel Mize) writes: > In article <31D95D93.28D8D15B@jinx.sckans.edu>, > David Morton 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