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