bearophile wrote:
(This comes from things that Lindquist has vaguely said, but I am not sure).
I am very ignorant about this topic still, so I can be quite wrong, but I think
it can be positive to split the D2 front-end in two layers, to simplify the
creation of D compilers:
1) A true front-end layer that's almost independant, that can be adapted to
different back-ends;
2) A middle-layer that performs some higher-order operations, like run-time
execution of functions, certain high level optimizations (like pure function
optimizations like pulling pure functions out of loops, and eventually some
delegate inlining), that can be missing in the DMD backend but already present
in LLVM. Such operations need to know semantics about the code, so LLVM by
itself may be unable to perform them.
So when you try to use LLVM to compile D code you don't touch the true
front-end, and you replace some of the parts of the middle layer with things
already present in LLVM.
Bye,
bearophile
Some simple lessons can be learnt from the clang project. Clang is
designed as a bunch of separate libraries so they can be used for
anything that needs to process c.
http://clang.llvm.org/features.html#libraryarch
In my opinion there should be one set of libraries (not limited to 2
layers) that is generalized enough to be used by any compiler, ide or
other tools for d too.
Not too long ago I noticed yet another "I've made a d ide" post. The
problem is that similar code used by other ides, and compilers is re
written again every time and each have a long life of bug fixing until
they can read the majority of d code and still have its flaws.
D.R.Y (don't repeat yourself). Even M$ is a victim of this when visual
studio ide thinks your C++ code is in error but the compiler handles it
just fine.
