Compilation strategy

Walter Bright newshound2 at digitalmars.com
Tue Dec 18 12:38:32 PST 2012


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 :-)



More information about the Digitalmars-d mailing list