Re: clang/emacs/ecb/semantic

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Richard Stallman <rms@gnu.org> writes:

>     Something that should have been merged into gcc a long time ago.
>
>     It generates the parse tree as xml.   http://www.gccxml.org/
>
> Do you mean, the entire parse tree in full detail?
> Would it be conceivable to feed this into a nonfree back-end?
> Would this mean that nonfree backends could take advantage
> of our free front-ends?
>
> If so, it is very dangerous -- it would open the door to a terrible
> setback for our defense of users' freedom.  Namely, the use of free
> software as part of compilers that are partly nonfree.  I don't
> remember, but I would guess that is why we have refused to merge it
> into GCC.

I can understand this reasonning.  But in practice the conclusion is
that Apple switches to llvm/clang, and llvm/clang as a lot of momentum
everywhere.

Wouldn't have been better to accept gcc-xml and have gcc cover 99% of
the "market", rather than rejecting it, and eventually have gcc left
with only 10% of the mind share, and clang/llvm 90%?  I'm afraid this
might end like that.


>     Llvm and clang provide natively a way to get the parse tree (and other
>     phases information), and therefore they can be used easily in IDE.
>
> LLVM and Clang open the door to the same terrible setback.  Since they
> are not copylefted, their front-ends can be used with nonfree
> back-ends and vice versa.

Definitely.  It's bad they're not GPL, and it's bad they're used in non
GPL environments.  But that's how things are.  llvm and clang are
providing a superior alternative to gcc for tool and IDE builders.


> They are being developed by people who don't care about users'
> freedom, funded by the worst enemy of users' freedom (Apple).

I don't know if Apple funds LLVM.  AFAIK it started as a normal
university project.

Would a good alternative (for freedom) to be that free compilers (GPL)
provide the exact formal grammar they parse, so that tool builders could
use it to write compatible parsers to use in their tools?

For example, now emacs has with cedet several parser generators
(bovinator, Wysent, etc), but they are not widely (easily) applied to a
large number of languages, because the grammars (of specific
implementations) are often not so easy to retrieve in a usable form.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.