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, 01 Mar 2014 17:01:43 +0100 Message-ID: <87vbvxykk8.fsf@fencepost.gnu.org> References: <87zjlf6tdx.fsf@fencepost.gnu.org> <83sir7yue7.fsf@gnu.org> <8761o3dlak.fsf@wanadoo.es> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87vbvzcjv9.fsf@engster.org> <87iorz18fy.fsf@fencepost.gnu.org> <87a9db15v8.fsf@fencepost.gnu.org> <8761nz0xje.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393689709 21376 80.91.229.3 (1 Mar 2014 16:01:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 16:01:49 +0000 (UTC) Cc: Juanma Barranquero , Richard Stallman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 17:01:57 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 1WJmMP-0004Rb-23 for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 17:01:57 +0100 Original-Received: from localhost ([::1]:60129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJmMO-00045t-Ao for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 11:01:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJmML-00045j-Qu for emacs-devel@gnu.org; Sat, 01 Mar 2014 11:01:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJmMK-0005HB-Ks for emacs-devel@gnu.org; Sat, 01 Mar 2014 11:01:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJmMK-0005H7-Hq for emacs-devel@gnu.org; Sat, 01 Mar 2014 11:01:52 -0500 Original-Received: from localhost ([127.0.0.1]:45527 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJmMC-0005as-A1; Sat, 01 Mar 2014 11:01:44 -0500 Original-Received: by lola (Postfix, from userid 1000) id CCB6DDF3C6; Sat, 1 Mar 2014 17:01:43 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Sat, 01 Mar 2014 10:34:12 -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:170003 Archived-At: Stefan Monnier writes: >> The point is to give people a strong motivation to implement the >> necessary support with GCC. > > I don't see how avoiding clang support in Emacs provides motivation for > GCC hackers to add this support, that's been lacking for several > years now. > > > Stefan "who'd favor a GNU clang effort, extending clang with new > exciting features distributed under the GPL" Well, if I understood correctly, part of the reason such support in GCC is not easily forthcoming is because of technical restrictions that are a consequence of policy decisions. So we are shooting ourselves in our own foot here. Inherently this boils down to the "viral nature" of the GPL, namely coercing newly created extensions to fall under the GPL automatically when distributed, requiring to cover a work "as a whole", and the point of modularity as a software design goal is to separate works into reasonably separate aggregates. This coercive nature of the GPL has bargained us the Objective C frontend to GCC. With a high amount of modularity and nice compiler building blocks, this frontend might have stayed proprietary. As it stands, Objective C is nowadays very much constrained to fringe status except on proprietary platforms like those of Apple. And I doubt GCC is used to any significant degree for compiling Objective C code. Which is disappointing. My personal preference would be to allow general purpose interfaces and modularity where they provide obvious benefit for Free Software development of uncoordinated parties. Of course, where the only imminent usage (and motivation for factoring out interfaces) would be by a proprietary program, the mere "it _could_ be used for Free Software" should not really drive forward a feature, nor should special cases be added for proprietary software. But the main problem we are dealing with is that modularity and general-purpose interfaces weaken the power of the GPL, while at the same time allowing for more reuse of software and for a better scaling of developers since they can drive their own projects forward in a less lockstepped manner. And the speed and lags of software development these days make lockstepped development really expensive. I am not sure that the balance regarding modularity and integration we are striking these days serves best our goals of promoting Software Freedom and extending the amount of copylefted software available and useful. The easiest way for a large number of people to cooperate, and there _is_ a large number of people writing copylefted software, is to make sure this cooperation requires a minimal amount of interaction, and that means modular and versatile tools. After all, that's what UNIX, after which GNU has been moduled, is all about. But we are obviously not going to turn on a dime regarding policies long in the making. -- David Kastrup