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: Tue, 13 Jan 2015 10:37:36 +0100 Message-ID: <8761cbhvhb.fsf@fencepost.gnu.org> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421141962 24139 80.91.229.3 (13 Jan 2015 09:39:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Jan 2015 09:39:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 13 10:39:17 2015 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 1YAxwS-0008N2-WE for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 10:39:17 +0100 Original-Received: from localhost ([::1]:38085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxwS-0005su-37 for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 04:39:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxvY-0004nZ-1K for emacs-devel@gnu.org; Tue, 13 Jan 2015 04:38:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAxvW-0000kS-Vw for emacs-devel@gnu.org; Tue, 13 Jan 2015 04:38:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxvW-0000kE-TV for emacs-devel@gnu.org; Tue, 13 Jan 2015 04:38:18 -0500 Original-Received: from localhost ([127.0.0.1]:39978 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxvV-0005mY-SP; Tue, 13 Jan 2015 04:38:18 -0500 Original-Received: by lola (Postfix, from userid 1000) id 2F7D8DF3B9; Tue, 13 Jan 2015 10:37:36 +0100 (CET) In-Reply-To: <54B456C8.6010506@gmail.com> (Jacob Bachmeyer's message of "Mon, 12 Jan 2015 17:20:40 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:181208 Archived-At: Jacob Bachmeyer writes: > David Kastrup wrote: >> Jacob Bachmeyer writes: >> >> >>> Perhaps there is a better option? I seem to remember efforts to adapt >>> Guile to run Emacs Lisp and then to port Emacs to run using Guile >>> instead of its own runtime. I'm not certain of the difficulty, but >>> perhaps GCC could be, over time, moved towards an option to build as >>> Guile extensions? I haven't looked far enough into this to know if it >>> is feasible, or how much work would be needed, or if I'm completely >>> mistaken and it isn't feasible at all. >>> >> >> That would be a solution that would favor integration of Emacs and GCC >> and make it convenient. But Lisp/Scheme/Guile is easy to parse, and >> easy to interface with other tools. That's the reason for Emacs' >> popularity, and the reason Guile is pitched as GNU's extension language. >> >> Anything that is feasible for combining Emacs with GCC will be feasible >> for combining proprietary tools with GCC. >> >> > Not quite in this case. The GPL would still apply to GCC built as > Guile extensions and therefore would still apply to any code that > calls into GCC through Guile, just like Guile's current readline > module. Guile puts everything into the same process and isn't "arm's > length" at all. > Emacs is GPL, so it can call into GCC through Guile with no problem. > A proprietary tool doing the same gets dropped right into a copyright > quagmire. Not if it does just the same as Emacs since that means it uses a generically useful interface. > Which leads to another idea that I think may have been mentioned: Does > Emacs have the ability to load C plugins from shared objects? No, and the reason is again not technical but political: it would make Emacs generally useful as a component in compound applications not reached by the GPL. At one point of time, we'll probably need to rebalance the needs for being able to rearchitecture and retool against the reach we would like the GPL to have. If we limit all our architecting choices to extensions in reach of the GPL of the original core, we won't be able to interconnect big independent GPLed applications, like Emacs and GCC are, because that would also provide the technical means to interconnect with a big non-GPLed application while keeping it independent. So the "plugins/AST for GCC" question and "callable modules for Emacs" question is pretty much tied down for the same reason: any reasonably powerful connection mechanism between Emacs and GCC will make it possible to connect Emacs with proprietary tools, and GCC with proprietary tools. I think it would be too expensive for us to _not_ pay this price. Throwing a spanner into modularity and versatility whenever things get interesting is going to be too expensive. I would state "we should be happy copyright can't reach everywhere", but with regard to software licensing that is not all that convincing since most "licensing" mostly relies on contractual conditions far exceeding copyright and consequently has not much control to lose from increased possibilities of interaction due to a changing technical landscape. -- David Kastrup