Compilation strategy

[H. S. Teoh]

On Tue, Dec 18, 2012 at 06:55:34AM -0800, Walter Bright wrote:
> On 12/18/2012 3:43 AM, foobar wrote:
> >Honest question - If D already has all the semantic info in COMDAT
> >sections,
> 
> It doesn't. COMDATs are object file sections. They do not contain
> type info, for example.
> 
> >  * provide a byte-code solution to support the portability case. e.g
> >  Java byte-code or Google's pNaCL solution that relies on LLVM
> >  bit-code.
> 
> There is no advantage to bytecodes. Putting them in a zip file does
> not make them produce better results.
[...]

An idea occurred to me while reading this. What if, when compiling a
module, say, the compiler not only emits object code, but also
information like which functions are implied to be strongly pure, weakly
pure, @safe, etc., as well as some kind of symbol dependency
information. Basically, any derived information that isn't immediately
obvious from the code is saved.

Then when importing the module, the compiler doesn't have to re-derive
all of this information, but it is immediately available.

One can also include information like whether a function actually throws
an exception (regardless of whether it's marked nothrow), which
exception(s) it throws, etc.. This may open up the possibility of doing
some things with the language that are currently infeasible, regardless
of the obfuscation issue.


T

-- 
There are three kinds of people in the world: those who can count, and those who can't.