Re: Separate compilation

Antoun Kanawati writes: 

Nic Ferrier wrote:
> This approach has not been popular because it requires a sophisticated
> runtime system ... all the divantages of compiled code with none of
> the benefits!

No, it's a reasonable solution. It's essentially equivalent to a
compiler that auto-generates "header files" for you, with the added
advantage that they're in object form. This permits much more
sophisticated dependency analysis than the traditional cc + make
approach. For example, the cc + make approach generally requires a
rebuild if the header comments or whitespace changes; the Java approach
can more easily ignore that kind of trivial change.

The biggest divantage is that it doesn't play nicely with make (and
similar tools) because you can no longer check dependencies based on
file timestamps alone. That's not a huge obstacle, but it's enough to
discourage advances in incremental compilation. C++ programmers know
this well; many of that language's misfeatures arose because the
designers were torn between "the right thing" and "the thing that would
work with make + cc + ld." Eventually, the designers realized that they
had little choice but to abandon traditional make and linker tech, but
not until after the old ways were firmly entrenched in the language (and
the minds of its implementors).

> But I think more generally you're argument is disengenous. It's not
> Java's storage of type information inside the class file that solves
> the seperate compilation issue, it's the lack of a meta language.

That's a matter of degree, not kind. The traditional separate
compilation model works well when a language only needs to share a few
declarations between compilation units (e.g., macroless C headers). It
creaks a bit once you add simple macros, inlined functions, and similar
stuff. It breaks down when you add the pervasive sharing you need for
extensive Scheme macros or C++ templates.

I don't know whether there's a good solution to this, but it seems to me
that traditional separate compilation is a historical quirk that must
adapt to suit modern language features.

> Since Java has no macro facility it is not possible to declare source
> code transforms and the source code is no longer needed to transform.
> So you can just use the object code to compile.

The same is true for macros; the compiler can work with object code
instead of source code. While that object code requires further
translation, the same is true for any object code above the transistors
& electrons level. The difference between macros and other kinds of
object code is not in the level of translation, but rather in the degree
of coupling to other code.
--
Bradd W. Szonye
http://www.szonye.com/bradd