D compiler layers

[Tim Matthews]

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.