Compilation strategy

[H. S. Teoh]

On Tue, Dec 18, 2012 at 08:12:51AM -0800, Walter Bright wrote:
> On 12/18/2012 7:51 AM, H. S. Teoh wrote:
> >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.
> 
> This is a binary import. It offers negligible advantages over .di
> files.

I was thinking more along the lines of things like fully automatic
purity, safety, exception inference. For example, every function body
eventually has to be processed by the compiler, so if a particular
function is inferred to throw exception X, for example, then when its
callers are compiled, this fact can be propagated to them. To do this
for the whole program might be infeasible due to the sheer size of
things, but if a module contains, for each function exposed by the API,
a list of all thrown exceptions, then when the module is imported this
information is available up-front and can be propagated further up the
call chain. Same thing goes with purity and @safe.

This may even allow us to make pure/@safe/nothrow fully automated so
that you don't have to explicitly state them (except when you want the
compiler to verify that what you wrote is actually pure, safe, etc.).


T

-- 
Тише едешь, дальше будешь.