Compilation strategy

[Walter Bright]

On 12/16/2012 4:48 PM, H. S. Teoh wrote:
> I've proposed this before: when compiling a library, the compiler should
> process everything into an intermediate form (perhaps even the IR that's
> used internally to integrate with the codegen), then save that as a sort
> of partially-compiled object format. This can either be in the form of
> an object file, or perhaps a custom D-specific format. Everything,
> including templates, function bodies, etc., is included.  Then when you
> import something from the library, the compiler simply loads the IR from
> the intermediate format and use that info to compile the code.

This offers nothing over a .di file.


> This eliminates the wasted time relexing and reparsing imported files
> every single time they're used,

Frankly, it's not much faster than parsing the .di file.


> and also suitably "hides" the
> implementation details of the library in a format that isn't easily
> read. (I mean, let's face it, if someone is desperate enough, he can
> reverse engineer *anything*, so imagining that shipping a binary is
> somehow "safer" than shipping a straightforward IR is nonsense. But in
> the reasonable case, the library being in IR should be disincentive
> enough for people to not try to break encapsulation.)

It doesn't hide the source in any effective way. There are enough Java byte code 
=> source translators around to prove that. It only takes one such tool to exist 
(and it's especially easy to create such a tool given D being open source).

An effective way to hide your implementation is to use PIMPL, which D supports well.


> This intermediate format can be in the form of some kind of hash table
> that the compiler can quickly look up referenced symbols from, so there
> will be almost no overhead.

I've done such (precompiled headers for C++), I've done .di files, and I've done 
Java bytecode. .di files are superior in nearly every way.