Re: Emacs contributions, C and Lisp

[John Yates <john@yates-sheets.org>]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Thu, Feb 20, 2014 at 6:53 PM, David Kastrup <dak@gnu.org> wrote:
>
> My guess is that switching off optimization, you'd not be all that bad.
>

I already assumed that a magic "give me completions" flag would turn off
optimization and code generation.  I am concerned about process startup,
I/O (even if the required headers are already in the block cache), lexing,
parsing and semantic analysis.  Remember, we are talking C++ here, not C.
 Trivial programs pull in mega headers (stl, boost, etc) with increasing
use of such wonderful language features as "Turing-complete template
meta-programming".

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

Let me state that more clearly.  Correct me if I am wrong but I believe
that RMS has never done any C++ development.  As such he has little
appreciation for the value C++ developers may attach to tools with deep
knowledge of C++ semantics.

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 used the word "competing" to mean "offering similar service or
functionality".  I did not intend to bring in any notion of relative
performance of generated code.

Splitting parser and code generator into separately
> usable components...


That is not the issue.  Given that the gcc backend can be linked with a
number of different frontends I assume that stubbing off a few functions
would provide a free-standing frontend.  OTOH if gcc wants to "compete"
with clang in the tools space it will have to provide interfaces for
querying and manipulating its symbol table and intermediate representation.
 That is some rather heavy lifting for a codebase not designed from the
outset with that goal in mind


> 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.
>

Do I understand you correctly here?  Did you just conceded my original
point, namely that while RMS does not want us to dissipate the pent up
demand that could drive gcc into the tool space, that transformation most
likely will never happen?  IOW emacs-based C++ developers are denied
valuable tools that are becoming ever more common in other development
environments based on a chimera.

/john

[-- Attachment #2: Type: text/html, Size: 4119 bytes --]