On 12/18/2012 11:23 AM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 09:55:57AM -0800, Walter Bright wrote:
On 12/18/2012 9:42 AM, H. S. Teoh wrote:
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.).
The trouble with this is the separate compilation model. If the
attributes are not in the function signature, then the function
implementation can change without recompiling the user of that
function. Changing the inferred attributes then will subtly break
your build.
And here's a reason for using an intermediate format (whether it's
bytecote or just plain serialized AST or something else, is irrelevant).
Say we put the precompiled module in a zip file of some sort. If the
function attributes change, so does the zip file. So if proper make
dependencies are setup, this will automatically trigger the
recompilation of whoever uses the module.
Relying on a makefile being correct does not solve it.
Inferred attributes only work when the implementation source is
guaranteed to be available, such as with template functions.
Having a binary format doesn't change this.
Actually, this doesn't depend on the format being binary. You can save
everything in plain text format and it will still work. In fact, there
might be reasons to want a text format instead of binary, since then one
could look at the compiler output to find out what the inferred
attributes of a particular declaration are without needing to add
compiler querying features.
The "plain text format" that works is called D source code :-)
