
Lead Emacs developer considering forking over GCC and AST issues - josteink
https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00171.html
======
earljwagner
Basically, a bunch of folks are trying to convince RMS to allow GCC to provide
more information about parsed C++ programs to Emacs. This would allow Emacs to
implement a bunch of modern types of program transformations, e.g.:
[https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00149.html)

Stefan Monnier, the lead Emacs developer, argues that this is important for
Emacs and he's willing to support people in creating a GCC plugin to output
this info. Linked post and also here:
[https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00091.html)

RMS's concern is that allowing GCC to output its internal representation
including the AST (Abstract Syntax Tree) would enable non-free software to
also use it as a preprocessor: [https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00015.html)

Perry E. Metzger points out that people are already using Clang+LLVM for
preprocessing: [https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00088.html)

He and others are concerned that LLVM has overtaken GCC in terms of mindshare
within academic research because of its modular structure:
[https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00141.html)

LLVM has an MIT/BSD-style license though, which RMS disagrees with:
[https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00162.html)

Meanwhile, Eli Zaretskii's trying to document the use cases for info from GCC,
so that a decision/design can be made with the full perspective:
[https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2015-01/msg00176.html)

~~~
tree_of_item
Eli's attempt to collect information seems well-intentioned but very silly.
There's no way to make some finite list of the things you might want to do to
enable an intelligent decision about what information to export from GCC. You
want to be able to do _everything_ , so you can write new program transforms
as you think of them.

Think of a Guile REPL with C++ syntax trees as values and a set of functions
mapping trees to trees. That's the sort of thing that would be very helpful in
thinking of what to do in the first place.

It doesn't sound like Richard would appreciate this scenario though, which I
find a little sad.

~~~
slowmovintarget
I hate to say it but RMS comes off as a bit petulant in this exchange. The
"I'd advise you to stop 'pressuring' me or else" bits in particular.

The other developers are trying to show him that he's keeping GCC crippled by
design in order to preserve freedom. They argue that in doing so, the affect
will be to drive people away toward more wide open tech, achieving the exact
opposite of what RMS hopes to accomplish.

When they cite examples of this already occurring, RMS responds with either a
shrug ("it's already happened, so we can't stop it") or with the
aforementioned "I'm offended."

Stefan asks point blank:

"Are you saying that if David writes this, and writes code for Emacs to make
use of it, you're going to use your leverage to try and make sure this code
doesn't make it into Emacs?"

To which RMS responds:

"We do not want to promote that sort of plugin."

That's kind of sad.

~~~
GFK_of_xmaspast
He feels a threat to his authority and ideology and is responding accordingly.

------
yellowapple
Per David Kastrup earlier in that thread:

> It is a greater problem for us to definitely block free applications from
> being developed, either completely or by putting up prohibitely high
> administrative or technical hurdles, than it is to accept the possibility of
> non-free ones here.

I think this is a good example of why trying to actively fight certain use
cases - in this case, potential use by non-free software - might as well be
considered harmful. In this particular case, clang/LLVM is proving itself to
be more free than GCC.

I'm a pretty strong free software advocate, and at this point, it's sounding
like LLVM is the way to go for even that reason alone. Deliberately crippling
a compiler to satisfy an ideological agenda does not encourage the development
of free software, especially in comparison to making a free software project
like LLVM that demonstrates the ways in which free software is better
software.

Basically, while I admire RMS' strong convictions, I'm beginning to believe
more and more that they're doing the precise opposite of what he - and many
other advocates of software freedom - actually want.

------
josteink
In advance: I honestly have no intention of doing link-baiting, but I found it
hard to summarize this submission accurately.

If anyone has any better suggestions, I'm all for it and encourage the mods to
change the title.

