Re: Emacs contributions, C and Lisp

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>  > "Stephen J. Turnbull" <address@hidden> writes:
>  >> David Kastrup writes:
>  >>> "Stephen J. Turnbull" <address@hidden> writes:
>  >>>> David Kastrup writes:
>
>  >>>>> It only weakens the GPL
>
> [big snip and back to David]
>
>  > The GPL can _always_ be enforced by the copyright holder.
>  > Collecting the assignments makes sure that the FSF has the full
>  > ability to enforce
>
> You could have stopped there.  *You* said "weaken the GPL" when what
> you really meant was "weaken the FSF."  OK, conceded.

It weakens the GPL when the FSF applies it to software where it cannot
hope to successfully defend the GPL in court.

> And then your main point:
>
>  > It doesn't weaken the GPL.  It weakens GCC, and with it, the GNU
>  > project.  Part of the strength of the GNU project lies with GCC
>  > setting language and performance standards,
>
> Except that last is now an exaggeration.  Obviously GCC no longer sets
> performance standards,

If you want to believe the summaries of Phoronix' Michael Larabel rather
than his numbers...

> and since the reason I switched my default to Clang was to get better
> error messages, in at least one aspect it seems to be lagging on
> language standard-setting.  (But see discussion below, especially
> fn. 1.)

You are confusing "being helpful with figuring out compliance with C++
standards" with "introducing its own features that are so good that
they are eventually accepted into standards".

GCC has had variable length arrays (also multidimensional) decades
before they made it into C99, and C++ still hasn't caught up.

>  > and it's bad if the most thorough modes we make available with
>  > Emacs are not able to support the GCC dialects.
>
> Now that, as Richard would say, is a misrepresentation.  Of course
> nothing prevents Emacs from supporting GCC dialects, certainly not a
> fiat from Mt. Olympus.  Of course Emacs *should* support them.

Of course Emacs could not possibly hope to support them if its language
parsing relied on Clang.  Which is what this thread is about.

> And if such support was lacking or weak, I think there's some chance
> that Richard would come around and encourage development of that mode.
> Don't you?

How can Richard encourage Clang developers to develop better parsing of
GCC-only features?  I think you overestimate his influence.

> AFAICS, the issue at hand is supporting unique features of free
> software whose licenses do not defend freedom according to Richard.

The issue at hand is relying on Clang as infrastructure for
cross-referencing/completing features in C/C++ modes.  The issue is
_not_ to "support unique features" but rather to have Emacs operations
_depend_ on unique features of Clang.  It's not the first time I've
corrected this statement.

> There are a lot of such licenses, including those used by TeX, Perl,
> Python, Ruby, ncurses, X11, and Apache.  Why doesn't the logic that
> applies to LLVM apply to them too?

Because Emacs does not rely on those to the detriment of GNU-internal
solutions of the GCC calibre and importance.

>  > So in this case GCC and the GNU project were in the situation of
>  > creating a de facto standard.  Once Emacs supports what Clang
>  > provides rather than what GCC provides, not even Emacs will support
>  > any new features of GCC.
>
> Hm.  You've said that twice, now.  This is a leap that I cannot
> follow.  Would you explain?

If Emacs only understands C/C++ by using Clang for its parsing, the
dialects it will support will be those of Clang.  This can't be that
hard to understand.

> I understand the rest of your argument that *compiler users* could
> abandon GCC en masse.  What I don't see is why that would prevent
> Emacs from supporting unique GCC features any more than it prevents
> Emacs from supporting a zillion true niche applications (eg, modes for
> .Xresource and RGB.txt manipulation).

Emacs does not get to choose which language features it supports when it
uses Clang for understanding source files.

> Furthermore, my personal estimate is that GCC's capacity for relevant
> innovation has been sapped by its dominant position and by the focus
> on internal issues that comes with high-stakes standard-setting.  And
> furthermore, refactoring to make internal data structures available to
> cooperating applications has been forbidden for a decade or so.  Just
> where are those "unsupportable" new features going to come from?

There has been no ban on "features".  Instead, the ban has been on
generic infrastructure making it easy to hack up features without
requiring changes to GCC.

Each individual feature can be supported by custom code in GCC.  The
cost of sacrificing modularity and generic interfaces is that
development and deployment of those features is then coupled to upstream
GCC development and its release cycles.

If the purpose of a discussion is to readjust the basis for
decision-making, constant misrepresentation of the salient points is
leading nowhere.  The way to tip a scale is not blowing it up.

> No, at least based on current behavior, you don't want *GCC* to *do*
> anything.  You want *LLVM* to *fail to innovate* in the same way that
> GCC is *prohibited* from innovating.  The effect is the same, but your
> statement suggests that GCC is being defended, when in actual fact
> what is happening here is that Emacs is being commanded to attack LLVM
> (in the sense of "trade war", ie, withdraw cooperation from an
> external entity whose competence threatens a protected local
> industry).

That's total rubbish and you know it.  Emacs is not "being commanded to
attack LLVM".  It is in no position to do anything of that sort.  And it
is most certainly not an "attack" if Emacs developers are told that
Emacs' C/C++ modes should not be equipped with features that can only
work by using Clang internally, consequently restricting the supported
languages and more important language dialects to those of Clang as well
as introducing a permanent dependency on a compiler not under our
control.

> This is only to the detriment of Emacs and LLVM users.

It is to the detriment of Emacs users who don't care about GCC and
ultimately the fate of the GNU project.  Yes.  The GNU project was never
about making everybody happy.  It was about making sure its users have
free software available where they have access to the full sources, and
making sure that this is not just a temporary state.  Whether or not its
users are interested in it.

It turns out that most aren't.  Which is hardly a surprise if you take a
look at the takeup of operating systems like Windows and MacOSX.

That GNU and GNU/Linux nowadays don't look ridiculous in popularity
contests does not mean that this is the metric we now should be
pursuing.  It is a dead end now as much as before.

> That justifies redoubling efforts to innovate in GCC, while respecting
> the self-imposed limitation on acceptable areas for innovation.  It
> doesn't justify "trade war".

It is no war if we decide what we are going to use ourselves as a
critical part of our infrastructure.  There is just no point in pulling
down our defenses in order to drag a pretty wooden horse in.

>  > When put to the choice, we'd rather give up on Android than GNU.
>  > And us having to take that choice at some point of time is what
>  > Clang/LLVM are working towards.
>
> I rather think you overstate the importance of GNU in the thinking of
> LLVM developers.

I think you utterly fail to comprehend that it does not matter at all
what LLVM developers think.  We have to take into account the effect of
their actions, not their motivations.

>
>  > Once Clang/LLVM become the compiler for Android, it is a matter of
>  > time and hipness before it becomes the default compiler for the
>  > Linux kernel.
>  > 
>  > Once the kernel is bootstrapped using Clang/LLVM, it is a matter of
>  > time before the userland of big distributions is compiled using
>  > Clang/LLVM as well, with GCC becoming optional.
>  >
>  > At some point of time, it will become harder to compile the Linux
>  > kernel with GCC out of the box, and bootstrapping a full GNU system
>  > will mean that we need to revert to the HURD, mostly relying on
>  > using Linux drivers.
>
> A sad future history indeed.  And you think that refusal to integrate
> Emacs modes that use Clang to improve the Emacs user experience

To improve the Emacs user experience for those users that are willing to
forego GCC as compiler

> is the finger in the dike that will save Holland, er, the GNU Project?

The GNU project started by sticking up a finger in a sea of propretary
software.  That's where it started, and it will end when nobody is
willing to stick up for it.  Complacency and resignation are not the way
to anything.

> The obvious fact is that GNU can't stop the process you've described
> -- it all happens outside of GNU!

Which means that if we cannot stop the processes outside of GNU, we can
at least keep things as they should be inside of GNU.  That is nothing
that can be taken away from us unless we give it up voluntarily.

> Specifically, it wants to be universal but denies the clearly
> expressed aspirations and preferences of the rest of the
> free-software-producing world and their users.

The GNU project never aspired "to be universal".  It has always been an
enclave because of a world that has gone mad in its laws and business
processes.  The FSF has a mission to make the world less mad, and it
would be great if at some point of time the GNU project would become
unnecessary because software was free anyway.  But making the world less
mad and maintaining GNU are two separate endeavors, and they will not
become the same in our life time.

> And now, it's denying the aspirations of some of its own members,
> merely to spite those with different beliefs about defending freedom.

Shrug.  What do you hope to achieve with inflammatory spins like that?
Trying to work with those resources one has under one's own control and
reducing external dependencies where feasible is Economics 101.  If I
tend to my own orchard instead of buying apples at the market, is that
merely to spite those merchants at the market with different beliefs
about planting trees?

-- 
David Kastrup