From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sat, 22 Feb 2014 18:17:37 +0100 Message-ID: <87mwhjdq32.fsf@fencepost.gnu.org> References: <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393089479 8233 80.91.229.3 (22 Feb 2014 17:17:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Feb 2014 17:17:59 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org, John Yates To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 22 18:18:07 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WHGDG-00042M-AH for ged-emacs-devel@m.gmane.org; Sat, 22 Feb 2014 18:18:06 +0100 Original-Received: from localhost ([::1]:50341 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGDF-0006KX-L0 for ged-emacs-devel@m.gmane.org; Sat, 22 Feb 2014 12:18:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGDC-0006KS-Os for emacs-devel@gnu.org; Sat, 22 Feb 2014 12:18:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHGDB-0007Vq-I0 for emacs-devel@gnu.org; Sat, 22 Feb 2014 12:18:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGDB-0007Vm-Eh for emacs-devel@gnu.org; Sat, 22 Feb 2014 12:18:01 -0500 Original-Received: from localhost ([127.0.0.1]:46050 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHGD4-0006rd-1x; Sat, 22 Feb 2014 12:17:54 -0500 Original-Received: by lola (Postfix, from userid 1000) id AED60E04FF; Sat, 22 Feb 2014 18:17:37 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Sat, 22 Feb 2014 11:28:53 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169814 Archived-At: 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. ]]] > > 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