Re: Emacs contributions, C and Lisp

[David Engster]

Jacob Bachmeyer writes:
> Obviously, it should still be possible to build "stand-alone GCC", but
> having the compiler be available from Guile could easily solve the
> issue at hand here, especially if the extension presents a Lisp-like
> API for the GCC internal structures.  This would also address the
> concerns about the GCC front-end being abused to feed nonfree
> backends, since the tree would only be present in memory behind a GPL
> interface.
>
> But this is years away at best

As always, people are needed to actually code that.

> and doesn't solve the immediate problem, which is that Emacs needs a
> parse tree "now".  There are three options for how to get that:
>
> (1)  Write a C parser in Emacs Lisp.

Already done. Works reasonably well for C, is lacking for C++. Improving
it would still be my first option, but no one is interested in helping.

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

There's no significant pain in looking up the names from the source
files. Also, I see absolutely no point in somehow obfuscating the AST,
since for feeding things like LLVM, there are much simpler options, like
you have noticed yourself (see below).

> Further, the refAST needs to resemble the source text as closely as
> possible.  Most of GCC's value is from the optimizer and code
> generators.  Parsing is relatively simple compared to the rest of GCC.

I don't think the guys maintaining the C++ frontend would agree...

> If the refAST is dumped after optimization, it will be next to useless
> for editing the source.  So the refAST must be dumped prior to any
> optimization.  My knowledge of GCC internals is lacking, but a glance
> at gccint suggests that Emacs needs a dump of GENERIC, which,
> incidentally, can "also be used in the creation of source browsers,
> intelligent editors, ..."

Yes.

> Further reading reveals that for better or for worse, this ship has
> already sailed and GCC has had an option to dump GIMPLE
> representation, which is probably far more useful for abusing the
> frontend than an AST dump, for some time now.

That's what I said from the beginning, and it's my main point why all
this discussion about somehow obfuscating the AST dump is so completely
absurd. My guess is that DragonEgg does exactly what you
describe. Richard chose to not respond to this fact.

-David