4 ms·

No, RMS's stance of plugins does make adding C++11 features to gcc much harder. I have a (basic) understand of clang, which is helped by the fact that there is

No, RMS's stance of plugins does make adding C++11 features to gcc much harder. I have a (basic) understand of clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM, which I can ignore the other side of. The interface between gcc front ends and backends is none of clear, simple or documented.

gsg 14y ago
Are you suggesting that C++11 support would be implemented as a plugin, rather than by modifying the existing C++ front end? I'm not sure how seriously to take that.
- CJefferson 14y ago
  No, I'm suggesting that understanding and modifying the C++ front end is much easier when the output the front-end produces is in well defined and documented output, rather than the ad-hoc and undocumented results of a gcc front-end.
  - gsg 14y ago
    Hmm? Front ends emit GENERIC, which is detailed at http://gcc.gnu.org/wiki/GenericAPI http://gcc.gnu.org/wiki/GenericAPI. I don't see what this has to do with RMS or plugins.
    - CJefferson 14y ago
      Have you scrolled down that page? It is an extremely brief introduction. The 'types' and 'functions' sections are completely empty, and the whole page amounts to 2 examples!
      - gsg 14y ago
        There's more at http://gcc.gnu.org/wiki/GENERIC http://gcc.gnu.org/wiki/GENERIC: my purpose was more to point out that an interface exists than to pinpoint the exact documents for you.
snogglethorpe 14y ago
> No, RMS's stance of plugins does make adding C++11 features to gcc much harder > clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM (1) People adding C++11 features to clang are not going to be dealing with LLVM, they're going to be modifying and extending clang's existing C++ parser. So however nice the clang-LLVM front-end-middle-end interface is, that's not going to have much impact on this job. Rather, what's important is the quality of clang's internal algorithms and data-structures (and those in gcc's c++ front-end). If clang does better there (dunno), that's great for them, but it has nothing to do with RMS's plugin position. (2) RMS is not against clean code, nice interfaces, good data structures, and good documentation. His concerns (whether you agree with them or not) are the degree to which interfaces are expressed in a way that circumvents the GPL. Good interfaces don't circumvent the GPL; So it's perfectly fine to clean up and document gcc's data structures and interfaces (and indeed, this is already happening, and has been for a long time). RMS isn't going to stop you.
- jonhendry 14y ago
  "GCC suffers from layering problems and leaky abstractions: the back end walks front-end ASTs to generate debug info, the front ends generate back-end data structures, and the entire compiler depends on global data structures set up by the command line interface." Chris Lattner, "The Design of LLVM" http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 http://www.drdobbs.com/architecture-and-design/the-design-of... (Seems possibly relevant to the boundary issue.)

gsg 14y ago

Are you suggesting that C++11 support would be implemented as a plugin, rather than by modifying the existing C++ front end? I'm not sure how seriously to take that.

CJefferson 14y ago
No, I'm suggesting that understanding and modifying the C++ front end is much easier when the output the front-end produces is in well defined and documented output, rather than the ad-hoc and undocumented results of a gcc front-end.
- gsg 14y ago
  Hmm? Front ends emit GENERIC, which is detailed at http://gcc.gnu.org/wiki/GenericAPI http://gcc.gnu.org/wiki/GenericAPI. I don't see what this has to do with RMS or plugins.
  - CJefferson 14y ago
    Have you scrolled down that page? It is an extremely brief introduction. The 'types' and 'functions' sections are completely empty, and the whole page amounts to 2 examples!
    - gsg 14y ago
      There's more at http://gcc.gnu.org/wiki/GENERIC http://gcc.gnu.org/wiki/GENERIC: my purpose was more to point out that an interface exists than to pinpoint the exact documents for you.

snogglethorpe 14y ago

> No, RMS's stance of plugins does make adding C++11 features to gcc much harder > clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM (1) People adding C++11 features to clang are not going to be dealing with LLVM, they're going to be modifying and extending clang's existing C++ parser. So however nice the clang-LLVM front-end-middle-end interface is, that's not going to have much impact on this job. Rather, what's important is the quality of clang's internal algorithms and data-structures (and those in gcc's c++ front-end). If clang does better there (dunno), that's great for them, but it has nothing to do with RMS's plugin position. (2) RMS is not against clean code, nice interfaces, good data structures, and good documentation. His concerns (whether you agree with them or not) are the degree to which interfaces are expressed in a way that circumvents the GPL. Good interfaces don't circumvent the GPL; So it's perfectly fine to clean up and document gcc's data structures and interfaces (and indeed, this is already happening, and has been for a long time). RMS isn't going to stop you.

jonhendry 14y ago
"GCC suffers from layering problems and leaky abstractions: the back end walks front-end ASTs to generate debug info, the front ends generate back-end data structures, and the entire compiler depends on global data structures set up by the command line interface." Chris Lattner, "The Design of LLVM" http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128 http://www.drdobbs.com/architecture-and-design/the-design-of... (Seems possibly relevant to the boundary issue.)