Potential of a compiler that creates the executable at once

Araq rumpf_a at web.de
Thu Feb 10 10:38:05 UTC 2022


On Thursday, 10 February 2022 at 09:41:12 UTC, rempas wrote:
> This is probably the best of both worlds!


It's a very bad idea, it's in fact so bad that I wouldn't call it 
a "design":

- Since everything is recompiled all the time regardless, there 
is no incentive for "modularity" in the language design. Nor is 
there any incentive to keep the compiler's internals clean. Soon 
everything in the compiler operates on an enormous mutable graph 
internally, encouraging many, many bugs.
- You'll likely run into memory management problems too as you 
cannot free memory  as everything is connected to everything 
else. Even if you are willing to use a GC the GC cannot help you 
much as your liveset simply keeps growing.
- Every compiler bugfix tends to add code to a compiler, so it'll 
get slower over time.
- The same is true for the memory consumption, it'll get worse 
over time.
- Every optimization you add to the compiler must not destroy 
your lovely compile-times. So everything in the compiler is 
speed-critical and has to be optimized. Almost anything you do 
ends up being on the critical path.
- This does not only affect optimizations (which can depend on 
algorithms that are O(n^3) btw) but also all sorts of linting 
phases. And static analysis gets more important over time too.

In summary: People expect optimizers and static analysis to get 
better too and demand more of their tools. Your "design" doesn't 
allow for this. And in an IDE setting you might be able to skip 
all the expensive optimization steps, but not the static analyser 
steps.



More information about the Digitalmars-d mailing list