Re: Emacs contributions, C and Lisp

[David Kastrup]

John Yates <address@hidden> writes:

> I would like to hear the gcc developers weigh in on whether such a tool
> (namely a variant invocation of gcc running through all of its lexing,
> parsing and semantic analysis) could ever be made to operate at speeds that
> would make gcc-based completion tolerable.

My guess is that switching off optimization, you'd not be all that bad.

> This goes to a crucial part of the discussion that I feel RMS fails to
> acknowlege.

"Fails to acknowledge" is not the same as "is not going to accept".

> Namely that clang is not a compiler frontend per se but a set of
> performance-focused components targeted at building C++-aware (often
> interactive) tools.  clang-based completion is not an invocation of a
> compiler built by grafting clang onto llvm but rather communication
> with a caching server built using clang components.
>
> We have existence proof that one can use clang libraries to build a
> C++ compiler competing with gcc.

Well, given the right article author.  If we are talking about the
conclusions of Phoronix, see
<URL:http://draketo.de/light/english/free-software/phoronix-distort-results-gcc-llvm-clang-amd-vishera>.

> I wonder how realistic it is to expect gcc to be turned into
> components enabling construction of tools similar to those using
> clang:
>
> http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1RefactoringTool.html
> http://clang-analyzer.llvm.org/
> https://code.google.com/p/include-what-you-use/
>
> To what extent does the "do not offer interfaces that might enable
> repurposing of gcc code for non-free projects" make it unlikely that
> such components might ever emerge?

Well, GNU offers awk, sed, ed, bash, cat, cut, paste, sort, tac, ptx,
bison, gcc itself and a number of other tools that can be used to build
and/or plug together proprietary applications from free components.

There are also specialized tools like idutils
<URL:https://www.gnu.org/software/idutils/manual/html_node/index.html>
that are explicitly intended to extract and provide program data.

And while it would be cumbersome to extract, it would be possible to
compile with -O0 -ggdb and get a lot of type info in the object file.

So there is quite a bit of precedence: this question is not a
black&white one but needs to get answered by weighing advantages and
disadvantages.  Splitting parser and code generator into separately
usable components that can be considered independent would allow using
GNU frontends with proprietary backends for selected
processors/coprocessors without causing the "software as a whole" clause
to trigger.

Or proprietary frontends (like the Objective C compiler once was) with
the code generator of GCC.

Allowing for either of these use cases is giving up a lot of control
over derivatives that is the principal motivation for the GPL.  The
disadvantage of that has to be weighed against the advantages.

Even when that has been done, one still has to do an actual
implementation and _then_ have to see whether under the constraints of
the current implementation the hoped-for advantages are actually as
envisioned, and the accepted drawbacks don't turn out larger than
expected.  And there is not much of an option to turn back the clock,
either.

In practice, there is not all that much willingness to do an open-minded
and open-ended investigation and accept the conclusions either way.
I don't exactly blame Richard for not being eager to open a can of worms
that is causing enough of a nuisance already while the lid is on.

-- 
David Kastrup