Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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.