Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     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.
>
>
> Remember that the main purpose of the GNU system -- including GNU
> Emacs -- is freedom.  Technical progress and convenience are
> _secondary_ goals.
>
> Copyleft is needed to defend freedom, which is why Clang is so harmful
> to our freedom.  There are already nonfree versions of Clang that do
> tremendous harm to our movement.

Quite so.  And there is no point in foregoing potential benefits in
order to protect assets that we no longer have exactly because Clang's
progress has demolished them.

> Allowing nonfree versions of GCC would not help us "win" anything that
> matters -- it would only mean surrender.

Sure, but nobody was talking about "allowing nonfree versions of GCC".
The problem in this discussion is that everybody is talking about
different endeavors, lumping everybody else into the camp of being
opposed to all the goals that he was proposing a project for.

In the context of context-sensitive completion, I see a variety of
actual rather than strawman proposals here:

a) let GCC output the whole AST representation of the input (whatever
that may be) on demand
b) split GCC into separate components with well-defined interfaces
c) create a plugin interface into GCC that is generic enough to provide
the completion stuff
d) extend GCC with specific code exclusively for the intent of providing
completion

None of that would "allow a nonfree version of GCC", but would to
different degrees allow using GCC as a component in a solution that is
not, in itself, free.  Of course, while at the same time allowing using
GCC as a component in a solution that is free.

What to do here depends on how one estimates the respective
probabilities of

a) liberally licensed solutions built on that base
b) GPLed licensed solutions built on that base
c) proprietary solutions build on that base

a) of course enables c) to a certain degree.  Since both a) and c) can
already build on LLVM and since the enthusiastic a) camp will forego any
GPLed solution (which galls them) as much as possible and the c) camp
will try avoiding getting the patent poison pill of GPLv3 in any form
(no solution containing GCC in any form is going to end up in the iOS
Appshop either way, for example), we don't need to bend over backwards
guarding the bag which the cat basically left already.

Which gives us leeway to consider the respective benefits for the task
at hand here, namely completion in Emacs, when looking at any of the
previously mentioned

a) let GCC output the whole AST representation of the input (whatever
that may be) on demand
b) split GCC into separate components with well-defined interfaces
c) create a plugin interface into GCC that is generic enough to provide
the completion stuff
d) extend GCC with specific code exclusively for the intent of providing
completion

I think that Richard already contacted GCC people about option d) so
we'll get this particular angle addressed.

Tightly purposed extensions within the GNU project will likely always be
manageable, and they should address the current problem of completion
fine.

However, they require dedicated extensions in upstream GCC and thus they
require project coordination and cause time lag in the order of years
before downstream can reliably expect to provide its users with working
functionality.

More generic interfaces to extension decouple work on GCC from projects
employing it and thus gives more freedom to create new solutions in a
timely manner.

This decoupling also decouples the control over the direction individual
projects are taking, with aim and licensing.

As I stated: in the current landscape, GPL and particularly GPLv3 with
its patent indemnification clause appear to me as enough of a nuisance
for most prospective code adopters that we stand little risk for a
proliferation of proprietary solutions containing GCC as one separate
component as long as Clang is available in its current state.

The worst case scenario basically is that Clang will end up a footnote
in history and we opened the possibilities of using GCC as a component
in a liberally or proprietarily licensed solution imprudently and cannot
get the lid back on that can of worms.

However, I consider it very unlikely that Clang will end up a footnote
in history all by itself.  Not by now.

-- 
David Kastrup