From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 13 Jan 2015 16:38:49 -0600 Message-ID: <54B59E79.9070101@gmail.com> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> <83ppaj4afw.fsf@gnu.org> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421188755 21743 80.91.229.3 (13 Jan 2015 22:39:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Jan 2015 22:39:15 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 13 23:39:09 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 1YBA7A-0004i5-44 for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 23:39:08 +0100 Original-Received: from localhost ([::1]:41747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBA79-0000OM-Dy for ged-emacs-devel@m.gmane.org; Tue, 13 Jan 2015 17:39:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBA75-0000OE-5A for emacs-devel@gnu.org; Tue, 13 Jan 2015 17:39:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBA73-000224-VV for emacs-devel@gnu.org; Tue, 13 Jan 2015 17:39:03 -0500 Original-Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]:34260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBA6t-00020V-QO; Tue, 13 Jan 2015 17:38:51 -0500 Original-Received: by mail-oi0-f46.google.com with SMTP id a3so4695953oib.5; Tue, 13 Jan 2015 14:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZQTYiq58zQEs7/qqTHI5hUMOZhl99/+kL3CCbY3N9EE=; b=UuP+JrsIgn0VKW1oGnXoDjWGUtER8GvPXIEeGLE4byE04VhVrwB/9ylXZUfzF/qeNQ 84sYOMQk1uA+PMpGgWgXiUjWJJKeeu7r0cch670WClqEAVT04ABr3sf5CQ6MbSN0VJvl 3JzA31s3zA8rmbXMHh7xv1dp0k/8rXTNGBP8vyAPP/8LZT0rGDyHK1dy/4qCAt24Tdd0 YHYshHBNRa8X95o3F5wb4zQLiYs9+DbgewIKk6e2H/4k0Geq+6YFpkKW5sPEEesdigDu 84AHq554Q8FhQhqgi68s8orDFPBb/dbSHCBUAu+Bt9t9MuzlBSroEjyB+3nr1qO/enmj kUdA== X-Received: by 10.182.48.137 with SMTP id l9mr470825obn.43.1421188731268; Tue, 13 Jan 2015 14:38:51 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-148-241.dsl.ablntx.sbcglobal.net. [70.133.148.241]) by mx.google.com with ESMTPSA id o93sm11162782oik.21.2015.01.13.14.38.50 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jan 2015 14:38:50 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 In-Reply-To: <83ppaj4afw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::22e 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:181242 Archived-At: Eli Zaretskii wrote: >> Date: Mon, 12 Jan 2015 17:20:40 -0600 >> From: Jacob Bachmeyer >> Cc: emacs-devel@gnu.org >> >> Which leads to another idea that I think may have been mentioned: Does >> Emacs have the ability to load C plugins from shared objects? > > Why would we need that? We _are_ the Emacs project, so we could > simply make whatever C code is needed part of Emacs. > > I described my "two plugins" proposal as a "ridiculous hack" with good reason: the only stable API involved is the API by which Emacs calls the plugin on its side of the link to GCC. The Emacs plugin I proposed is essentially a piece of GCC loaded into the Emacs process and would be (as much as practical) independent of the version of Emacs used and very much dependent on the version of GCC used. A different Emacs plugin would be needed for each version of GCC whenever the relevant internal data structures change. This would, in practice, require that the stable API used be defined by Emacs, and a plugin (for Emacs) implementing the API be provided by GCC, for each version of GCC. If this API is well-designed, other language implementations could also implement plugins to provide ASTs to Emacs. Similarly, other Free editors could use the Emacs plugin to load AST data from GCC and other language implementations that provide their own plugins. All of this is a temporary measure and the basis for (part of) a future GCC Guile module interface (which would not have the IPC part, since GCC/Guile would then be in the Emacs/Guile process). With similar (hopefully minor) modifications, other Free editors could likewise embed Guile and gain the benefits of access to GCC's AST since the plugins would then be obsolete and discontinued. Due to GCC's license (the GPL), nonfree tools would not be able to use any of this. The interim Emacs plugin either (1) reads a more-or-less binary dump of GCC data structures or (2) accesses GCC data structures via some tightly-coupled IPC mechanism (shared memory?) either of which would be provided by a matching GCC plugin. The idea was that this would bring any user of the Emacs plugin under the GPL's scope with respect to GCC, because it's essentially an API into GCC. This is, of course, no problem for Emacs, which is itself GPL. Nor would it be a problem for any other Free editor, which could use the same plugin as Emacs does. It would be a problem for nonfree tools, since the Emacs plugin needed to access the data would be GPL and deeply intertwined with its matching GCC plugin and version of GCC. Why this sort of ridiculous hack, you ask? Because I'm trying find a way that GCC can export an AST such that the GPL comes with it. In other words, I'm trying to find a solution that makes both Emacs (get the AST) and RMS (don't let nonfree software have the GCC AST) happy. Having vaguely defensible technical benefits (efficiency, other Free software also gets the AST) would be the icing on the cake. Simply running them both in Guile solves this problem nicely, but will be a long way off. The ridiculous hack is something that can be implemented "now"-ish, at least in theory, if someone who understands the problem space well enough sets out to do it.