3 ms·

Unfortunately not. For years people wanted gcc to output a nice parse tree for C++, which would have been plenty useful for open source text editors, but was ba

Unfortunately not. For years people wanted gcc to output a nice parse tree for C++, which would have been plenty useful for open source text editors, but was banned by RMS as it would also be useful for closed source systems.

phkahler 7y ago
Not sure, but I think his concern was more about the introduction of opaque steps being introduced in the compiler and becoming something people depend on. A weak analogy might be nVidia drivers on linux, imagine a new arch where part of the toolchain is a closed blob. It turns out that hasn't happened yet with LLVM and allowing such things under LGPL may have worked.
- craftinator 7y ago
  I agree with this point of view; the three E's, Embrace, Extend, Extinguish, are already rampant in the compiler industry, and I see his choices as sacrificing ease of use for more transparency.
JoshTriplett 7y ago
This was a legitimate concern, which helped in the days GCC originated in, and hurt later on. Parsing C and C++ well and doing intermediate code generation and optimization was the hard part; taking the result and generating code for a target architecture might well have been proprietary for many architectures if it had been allowed to be, in the era when UNIX and other OS vendors were fighting against each other for every scrap of differentiation. And frontends for some languages would have been proprietary, as well. LLVM's extensible architecture was its most critical property; its permissive license is an unfortunate side effect of a rewrite. If GCC had come up with the "GCC Runtime Library Exception" way back in the day, and provided a modular architecture, half the innovation happening around LLVM might have happened around GCC instead. (Might, not "would have"; we can only speculate on what alternate history might have occurred.)

3 ms·

Unfortunately not. For years people wanted gcc to output a nice parse tree for C++, which would have been plenty useful for open source text editors, but was ba

by CJefferson 7y ago

phkahler 7y ago
Not sure, but I think his concern was more about the introduction of opaque steps being introduced in the compiler and becoming something people depend on. A weak analogy might be nVidia drivers on linux, imagine a new arch where part of the toolchain is a closed blob. It turns out that hasn't happened yet with LLVM and allowing such things under LGPL may have worked.
- craftinator 7y ago
  I agree with this point of view; the three E's, Embrace, Extend, Extinguish, are already rampant in the compiler industry, and I see his choices as sacrificing ease of use for more transparency.
JoshTriplett 7y ago
This was a legitimate concern, which helped in the days GCC originated in, and hurt later on. Parsing C and C++ well and doing intermediate code generation and optimization was the hard part; taking the result and generating code for a target architecture might well have been proprietary for many architectures if it had been allowed to be, in the era when UNIX and other OS vendors were fighting against each other for every scrap of differentiation. And frontends for some languages would have been proprietary, as well. LLVM's extensible architecture was its most critical property; its permissive license is an unfortunate side effect of a rewrite. If GCC had come up with the "GCC Runtime Library Exception" way back in the day, and provided a modular architecture, half the innovation happening around LLVM might have happened around GCC instead. (Might, not "would have"; we can only speculate on what alternate history might have occurred.)