Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <address@hidden> writes:

> I've been reading this in the list archives and as a long-time
> GNU/Linux user, feel the need to chime in.
>
> 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.

I don't see a way to hack ourselves around that.  Other GNU tools like
Make and Bison have options to dump their complete parse tree and/or
underlying data sets, and there are some applications making use of that
(sometimes just for debugging purposes: try tracing down shift/reduce
and reduce/reduce conflicts without an extensive dump).  Of course, they
are not as "mainstream" as context-sensitive programming editors.

> 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.

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.

-- 
David Kastrup