[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: Mon, 12 Jan 2015 17:20:40 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

David Kastrup wrote:
Jacob Bachmeyer <address@hidden> 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.

A more useful question is "How can GCC most efficiently provide an AST
to Emacs?"  Part of the answer is that Emacs already has the complete
text of every file involved.  Emacs doesn't care what the name of a
variable is--that's already in the buffer.  Emacs cares what part of
the buffer corresponds to a variable name.  Dumping an AST that
contains only annotations to text, referring to positions in the
source files instead of actually including text in the AST, looks to
me like a good middle ground.  Such an AST (which I will call a
"refAST" because it contains only references to program source text)
would be a significant pain to use as compiler input, since the symbol
names are missing, while also being exactly the information that an
editor needs.  We can make it harder to use the refAST to abuse the
GCC frontend by the same expedient that makes the refAST easier for
Emacs to read.  Emacs already has the source text, why force it to
read duplicates from the AST dump?

That's basically the "make things as convenient for Emacs" road.  But
anything Emacs can do, comparatively simply external programs can do.
We can (and should) favor Emacs, but we won't be locking out non-free
uses of the same data set in that manner.

Correct, an external program could easily enough convert a refAST back into a full AST. The goal is to make things as convenient for Emacs (and other editors, particularly Free ones) as possible, while also making a proprietary developer's job harder, particularly reading it into another compiler. While convenience for Emacs is more important than pain for others, having only locations in the AST dump provides both, except for other editors.

Technically, what's good for Emacs is good for other tools.  And I don't
see a licensing hack working within copyright law that would give us the
power to discriminate since copyright does not extend to program
interaction and we are working with licensing rather than contracts,
namely giving additional permissions over what copyright allows.

The limits of the GPL's reach, as best as I can see, is "arm's length", whatever that precisely is. In any case, the position I've always seen taken is that linking, especially when using a novel API, is within the scope of "derived work" and thus can be subject to requirements in the GPL.

Which leads to another idea that I think may have been mentioned: Does Emacs have the ability to load C plugins from shared objects? That would open two new options: (1) a very efficient binary dump format that is a huge pain to read, unless you are using the provided (GPL, of course) library that would be very efficient, but would have knowledge of GCC internals, and (2) a GCC plugin that holds compilation after parsing and exposes the AST through some tightly-coupled IPC mechanism to a corresponding Emacs-side plugin. Both of these options require a more-or-less stable API presented to Emacs, but work best with a platform-specific ball-of-mud link between Emacs and GCC, both ends of which should probably come from GCC. Passing GCC internal structures and references thereto over the link should be encouraged, as long as the editor side in the end gets a full AST (or at least an interface to one) without too much difficulty. Because the Emacs plugin would need a stable API, it could also be used by other Free editors, but because it would be GPL, proprietary software would not be permitted to use it. This is basically a simpler, "make something quickly" version of the longer term Guile/Emacs/GCC combination, which should remain a goal, both to get rid of this ridiculous hack I propose here, and to make GCC more available to other programs under the GNU system as well.

reply via email to

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