[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Tue, 13 Jan 2015 16:38:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Eli Zaretskii wrote:
Date: Mon, 12 Jan 2015 17:20:40 -0600
From: Jacob Bachmeyer <address@hidden>
Cc: address@hidden

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.

reply via email to

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