• bearophile (7/7) Nov 25 2009 (This comes from things that Lindquist has vaguely said, but I am not su...
• Tim Matthews (15/25) Nov 25 2009 Some simple lessons can be learnt from the clang project. Clang is
• retard (15/27) Nov 26 2009 But many of us use D as a hobby and attend basic compiler construction
• bearophile (4/7) Nov 26 2009 I know, Clang design is probably better. But it's a very different desig...

bearophile <bearophileHUGS lycos.com> writes:

(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

Tim Matthews <tim.matthews7 gmail.com> writes:

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.

retard <re tard.com.invalid> writes:

Thu, 26 Nov 2009 16:22:26 +1300, Tim Matthews wrote:

 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.

But many of us use D as a hobby and attend basic compiler construction 
classes at schools even as we speak. It would be boresome to use existing 
code and wouldn't boost the learning process. It's also very common that 
the implementation languages or the licenses differs. A set of libraries 
would have to be written in some portable language like C. Most of us 
want to use D instead. Some of us like BSD, some GPL, and a small part 
even develops proprietary tools for D.

Some might say that it's even benefical to have a rich set of tools - if 
you run into ICE, another D compiler/IDE might not fall into that trap. 
It also helps fixing the spec since currently it's not possible to 
develop two nearly identical compilers (without using dmdfe) because even 
dmd violates the spec in many cases. And when you ask Walter how it /
should/ work, he remains silent (for instance in the case of protection 
attributes when inheriting from a base class - class foo : protected bar)

bearophile <bearophileHUGS lycos.com> writes:

Tim Matthews:
 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.

I know, Clang design is probably better. But it's a very different design. What
I am asking is an improvement of the current D2 front-end code to allow its
better usage with the LLVM backend. I'm asking to separate better the
compilation phases.

Bye,
bearophile