Re: Mutually dependent private types

[fjh@cs.mu.oz.au (Fergus Henderson)]

John Volan <johnv@ac3i.dseg.ti.com> writes:

>Fergus Henderson wrote:
>> 
>> Geoff Bull <gbull@acenet.com.au> writes:
>> 
>> >How does a compiler that uses a non source based compilation library
>> >"with" a package that hasn't been compiled yet?
>> 
>> You can implement this by breaking up "compilation" into several
>> stages.  For example, the Mercury compiler (which supports a module
>> system similar to that of Ada) supports circular dependencies
>> with a non-source-based compilation library by breaking compilation
>> into the following stages:
>
>Without knowing anything about Mercury as a language, I can make the
>following observations:
[...]

Yes, your observations were all correct.

>These three levels of compilation are completely consistent with the
>inter-class dependency model I described in my diagram in
>http://bluemarble.net/~jvolan/WithingProblem/FAQ.html#missing_feature.

Right.

Actually there is one additional complication in our latest
development version.  I've been extending the Mercury module
system to support nested sub-modules with seperate compilation
(a bit like Ada's "is separate", or like Ada's child modules).
This means that some compilation units have access to the
things declared in the implementation of the parent module.
Thus in addition to the "short interface" and the ordinary interface files,
the Mercury compiler also produces "private interface" files, which actually
specify the interface that a parent module exports to its sub-modules.

>I am certain that these three compilation passes are exactly what occurs
>implicitly inside compilers for languages such as Eiffel and Java, where
>each class only has one source file and there is no explicit separation
>of forward declaration, interface, and implementation.  The only
>difference is that apparently the Mercury compiler needs to be
>explicitly told when to do which compilation passes on which modules in
>which order.  This compilation-order dependency is definitely
>reminiscent of old-style Ada compilation systems.

Well, the compiler itself needs to be explicitly told.
That's just because we made a design decision that resolving
the dependency ordering issues would be the job of a seperate
tool called "Mmake".  Generally the user interacts with Mmake,
rather than with the compiler directly, so the user never needs
to specify dependencies explicitly.

...
>> The above preconditions are recorded in dependency
>> files, and then we use a tool based on GNU Make to ensure that the
>> compiler is invoked with the appropriate options in the appropriate order.
>
>Old-style Ada compilation systems usually included a "make" tool that
>was able to do approximately the same thing. These usually had to do an
>"analysis" pass over the source files in a library to determine what
>units they contained and what dependencies there were between the units.

Yes, the Mercury compiler has an analysis pass (`mmc --generate-dependencies')
which writes out dependency information that is use by Mmake (the
Mercury make tool built on top of GNU Make.)

I seem to remember the old Ada implementations getting a lot of bad
press about problems with compilation order.  Why did that happen?
Was the criticism well-founded?
Did some Ada implementations not provide a "make" tool?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.