[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Mon, 24 Feb 2014 19:13:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Richard Stallman <address@hidden> 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. ]]]
>     > 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.
> As a general statement, that is valid -- but I think you're
> overestimating Clang's effects on GCC.

"tremendous harm to our movement" were your words.  Of course, Clang's
effects on GCC are not more or less than which changes we do and permit
doing to GCC.  But the impact of changes to GCC on the rest of the world
is no longer the same due to Clang.

Since we now have our house back to ourselves, we can rethink the rules
we had to make to keep the worst guests from misbehaving.  They've made
themselves at home with Clang now (and I think that the GPLv3 was pretty
effective with that) and it's just a question of time until the brawls
start up there and everybody erupts in proprietary variants and patent

>     > 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".
> Actually yes they were (though not with those words).  Someone cited
> my decision against having GCC write a complete syntax tree.  That
> output would make it easy to use GCC as a front end for nonfree
> back-ends.  That would be tantamount to making nonfree versions of
> GCC.

I disagree.  M4 output can be used as input for nonfree tools, but if
somebody ties GNU M4 into some task with non-free programs, that is not
tantamount to making a nonfree version of autoconf.

And it's not like a "complete syntax tree" representing all information
passed between GCC front- and backend could hope to retain stability
between versions.  So I think the "complete syntax tree" angle is mostly

What's definitely less hypothetical is getting at selected subsets of

> Splitting up GCC would have the same effect.

I'm not sure about that.  If a GPLv3 licensed subpackage does a smaller
job than the whole of GCC, I think that also the willingness to swallow
the accompanying GPLv3 poison pill in return for employing that package
would become correspondingly smaller.

So I am less than convinced that more modularity would lead to a
proportionally larger uptake by proprietary vendors than by the Free
Software community itself.

> The lookup and completion features that people want can be implemented
> by making GCC answer questions sent to it, as Aspell does for M-$.

Yes, most definitely.  And a special-cased approach like that would more
likely than not show better performance than one built from modular
building blocks.

But the organizational cost is high.  You can't hack up and play around
and have a working prototype of an Emacs package in weeks.  It takes
months to arrive at a prototype accessible to people compiling their own
GCC, and years for those who install stock versions of GCC.

Much of the UNIX philosophy revolves around having a versatile toolbox
allowing for rapid prototyping: the most important utility for a good
programmer, scientist, or writer is the wastebasket.

Being able to do experiments cheaply is one of the tenets of hacking.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]