Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer <jcb62281@gmail.com>]

Eli Zaretskii wrote:
>> Date: Mon, 12 Jan 2015 17:20:40 -0600
>> From: Jacob Bachmeyer <jcb62281@gmail.com>
>> 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.