Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

David Engster wrote:
> Jacob Bachmeyer writes:
>   
> > 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).
>
>   
It's not so much intentional obfuscation, as obfuscation as a 
side-effect of optimization.  Admittedly, a refAST is simple to convert 
back into a full AST, but doing so is an effort that should give a hint 
that "you are not supposed to be doing this".

> > 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...
>
>   
Then C++ is even more complex than I had thought.  I last used it for a 
freshman course in college some years ago.

> > 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.
>
>   
Not quite.  DragonEgg is actually a GCC plugin, so, rather than reading 
a GIMPLE dump, it gets the data from memory and splices the LLVM backend 
into the GCC compiler process.  It is GPL.  Any parts of LLVM it uses 
have to be licensed compatibly with GPL terms.  So DragonEgg can't 
(directly) use a nonfree backend with GCC, although it can dump LLVM IR 
which could then be fed into a non-free backend, but distributing such a 
system would have the legal uncertainties of whether you really can obey 
that particular letter while flagrantly violating the associated 
spirit.  From what I understand, Apple was considering something like 
that, but decided that developing Clang from scratch was a better idea.