Re: Emacs contributions, C and Lisp

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Juanma Barranquero <address@hidden>
>> Date: Fri, 28 Feb 2014 18:31:53 +0100
>> Cc: Emacs developers <address@hidden>
>> 
>> It would be interesting to measure (somehow ;-) whether that "Emacs
>> leverage" is enough to preserve GCC's importance. I mean, if using
>> the clang libraries allows much powerful, developer-friendly
>> environments for C/C++ programmers, do we think that a significant
>> number of them will still choose GCC because of Emacs? If the answer
>> is "yes", Richard's position strenghtens GCC without prejudice for
>> Emacs. If the answer is "not", that position hurts Emacs without
>> helping GCC.
>
> I actually don't understand why are we talking about compilers as the
> only viable infrastructure for the features being discussed.

It's basically the UNIX philosophy to employ dedicated tools for the job
they have been written for.  Parsing is a nontrivial task, so using an
existing parser makes sense.  Particularly when we are talking about
languages with complex namespace and type rules and overloading and
ambiguous grammar and three aspects of compiler technology
(preprocessing, normal execution, template instantiation) working
largely independently with partly surprising consequences.

Now we only want to have parsing and no code generation.  That's a kind
of task that GCC does not currently offer separately, and part of the
reason for it is that others might find it useful for creating non-free
applications around such functionality.

It's my opinion that this is a cost we hardly can avoid paying without
also creating serious road blocks for the creation of free tools.  In
the context of possibilities to refactor GCC to make parts of it
separately useful and/or allow other ways of plugging things together,
Richard tends to be conservative, and indeed it's a cat that would be
pretty hard to stuff back in the bag if one eventually finds the
consequences different than what one hoped for.

In the current situation, the GPLv3 with its patent protection clauses
provides enough of a disincentive in my book that one would have to be
overly afraid of creating proprietary spinoffs in the compiler
technology area.  However, there _are_ hopeful signs that the current
patent madness will eventually be fixed by legislational means, and in
that case the patent clauses of the GPLv3 would be quite less of an
influence on a big proprietary business' bottomline.

But should patents lose much of their sting, it would also mean a hit in
the general attractiveness of LLVM over GCC: the GPLv3 is more or less
cited as the main reason several proprietary vendors stopped working
with GCC.  So _iff_ the poison pill of the GPLv3 would become inert, we
have a situation where we'd want to be able to play to our strengths for
making proprietary vendors (and others) pick the GCC and thus provide
their users with some degree of freedom.

And that will basically happen on technical merit.

> We already have elaborate infrastructure for this kind of features:
> CEDET and in particular Semantic.  Moreover, we included CEDET in
> Emacs several releases ago precisely _because_ we wanted to move in
> the direction of making Emacs a better IDE.  If we need more of what
> is in ECB and the upstream CEDET, we can bring that in.  This is IMO
> the preferred direction: make Emacs features depend on nothing but
> Emacs packages.  Then all this prolonged discussion about GCC vs clang
> is a moot point, and we also gain independence of other projects'
> priorities and policies as a nice bonus.

Well, if we get to stage where we can say "get a language supported by
GCC, and Emacs will provide good highlighting, semantic completion, nice
formatting", then that would be a very strong selling point for GCC as
well as Emacs.  In particular if the output enabling those kinds of
feature can be used by other IDEs than Emacs.

And that's exactly because it would avoid duplication of work.  However,
it would also require incremental parsing to be really good.  Could an
incremental and/or differential parser (reparse just part of a file and
update all info about the whole compilation unit) be fit in the GCC
framework?  An interesting starting point would be, of course, trying to
make Bison skeletons that work for that purpose.  Unfortunately, the
highest-profile languages by GCC don't use Bison IIRC.

An any rate, it is a much more realistic goal to get 60% of all computer
users to use GCC than it is to get 60% of all computer users to use
Emacs.  And compilers are really important.  We should really think
about how we can leverage GCC to make, say, manufacturers of proprietary
hardware open up their hardware in order to use GCC rather than just go
somewhere else.  And that's a somewhat pressing problem.

> If we need policy decisions in this matter, _that_ is the only one
> that should be made.  To me, it is almost a no-brainer; I wonder why
> it is not clear-cut to others here.

The main problem I see here is that our policy decisions regarding Emacs
are, to a large degree, trickle-down decisions because of the role GCC
can or should play for computing.

In the concrete situation we have here, basically company-mode offering
semantic assistance based on Clang/LLVM, the solution I'd have preferred
to see is, "Oh, that's a shortcoming, but easily fixed.  Let's just hack
up something that works with current GCC, and then people have a
choice."

The current situation with GCC is such that "let's just hack up
something that works with current GCC" seems to be out of reach.  There
are two ways to address that: one is hacking something up in GCC that
works for that particular purpose.

We have the statement here (and far too little attention has been paid
to it) that -fdump-xref and associated programs of the GNAT project
would do the trick for the editing task currently at issue.  So there is
a prototype people could be testing and experimenting with instead of
doing flame wars.

It means using a specific version of GCC, but it would be easy enough to
turn that into a default version if we consider that a priority.  And I
think we should.  Really, really, really.

That could be a feasible approach to address the "batch data collection
for semantic completion" angle.

Now the Ada thing is a stroke of luck in its timing, and we should not
waste it.

But that still gives the question: "how about the longterm viability to
use GCC and its parsers to hack up something fast that does not require
changes to GCC"?

Because this would avoid all the discussion and friction and give people
the freedom to hack up their own solutions centered around GCC.
Including solutions we don't want to see.  I think that in this
particular case, the cost of tight control beyond that offered by the
GPLv3 (which will likely change along with the patent landscape) for the
underlying code base) is likely to be a cause for repeated roadblocks of
the kind we are seeing here with Emacs.

This particular Emacs flame war has been less than pretty.  But it is
more or less a downstream flamewar.  The current code and also partly
policy situation with GCC are what are at issue here.

While this particular situation might be curable with -fdump-xref
eventually, the respective decision-making in the context of Emacs
appears heavy-handed, and there are few other applications where a heavy
hand could even reach.

So I think that a long-term tenable solution of the problem will require
work and/or policy changes on GCC that would have made this a non-issue
or moderate-effort issue for Emacs.

To get back to what I replied to:

> This is IMO
> the preferred direction: make Emacs features depend on nothing but
> Emacs packages. [...]
> If we need policy decisions in this matter, _that_ is the only one
> that should be made.  To me, it is almost a no-brainer; I wonder why
> it is not clear-cut to others here.

Well, that is not really much in need of a policy since Emacs can
support multiple feature sets.  I would prefer if we needed no policy
decisions at all in this matter.  We don't get that, obviously.  But my
next preference is to have GCC move/develop in a manner where we would
not have needed a policy decision.  Because Emacs is, all in all, not a
particularly effective venue for making policy decisions matter in the
great play.  If we can get to a stage where our preferred action would
also be in accord with running policies, that means that the preferred
action in non-policed applications would be the same.

In other words: things are going wrong with GCC policies upstream
regarding reusability in Free Software applications that Emacs, as one
compiler user, is too small too fix.

If this is not approached in a more general manner in GCC, we'll have
this problem reoccuring in various iterations on the Emacs list, and it
will be reoccuring for the maintainers other Free Software which will
then choose to pick non-copyleft compilers entirely instead of playing
mix-and-match games or writing their own parsers.

-- 
David Kastrup