emacs-devel
[Top][All Lists]
Advanced

[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: Sat, 22 Feb 2014 07:47:08 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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

> Richard Stallman 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. ]]]
>  > 
>  >     > Whatever features we put in Emacs for interacting with a compiler in
>  >     > any fashion should work with GCC.
>  > 
>  >     Only to the extent that GCC supports that feature.
>  > 
>  > This decision applies also to features that GCC doesn't yet support.
>  > The outcome we want is that GCC supports them and Emacs uses GCC.
>  > 
>  > Emacs should not aim to advance by helping LLVM push GCC down.
>  > 
>  > If you need specific features added to GCC, please tell me.
>
> In this particular case, you've been told that outputting fully
> annotated ASTs is a desirable feature, and you decided it's a bad idea
> (for software freedom) to support it because it allows nonfree
> frontends and backends to be written for GCC backends and frontends
> respectively.  So you've opposed GCC support for that feature.

I think it makes some sense to reevaluate this particular choice.  If we
take a look those parties most likely to exploit it, they have moved on
to LLVM mostly.  _And_ they tend to consider the patent clauses of the
GPLv3 a poison pill for any use anyway.

I don't see that the information we are talking about will make it
reasonably straightforward to substitute backends and arrive at a
competitive compiler, though compilation speed is of course secondary to
runtime speed.

So I think that the existence of both LLVM and GPLv3 lessens the
positive impact from the decision while not really changing the negative
consequences.  There is a valid point about not giving people ideas
about how to outnavigate what the GNU project can achieve with the GPL
by introducing projects like LLVM.  But GCC seems rather too important
to cede a tactical loss like that here.

> In this case you need to choose between allowing any LLVM feature to
> be supported because it's free software, or saying LLVM may be free
> software but the feature it supports that GCC doesn't is freedom-
> denying, and therefore no matter how useful it may be, Emacs is not
> going to support that feature.

Well, the last point is where we at nowadays.  I think it makes sense
reevaluating the previous choice and thus making this one moot.  But
yes, that's Richard's call to make, and it would take quite a lot of
time and work to follow up on the consequences of changing that bit.

-- 
David Kastrup




reply via email to

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