[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs contributions, C and Lisp
From: |
Achim Gratz |
Subject: |
Re: Emacs contributions, C and Lisp |
Date: |
Sun, 11 Jan 2015 21:06:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Mario Lang writes:
> While I also think this attempt to cage data is rather absurd, I think
> there is likely another misunderstanding. What Clang currently seems to
> do for editor integration seems to match Richard's vision.
That may be the case, but the contention RMS is having revolves around
the ability to use this facility to make a non-free backend (or at least
that's my understanding of it). An overt dump of the AST is ostensibly
not necessary to cross that threshold.
> While they have functionality to dump the full AST, clang-format,
> clang-query, clang-rename and the completion interface don't expose a full
> AST at
> all. The idea behind the Clang tools is that they parse the translation
> units on their own, and do manipulations on the data internally. You
> pass parameters to these tools, like a position in a file you want to
> see completions for, or a range of locations to reformat, or a matcher
> expression to search for particular AST constructs.
[…]
Looking at the documentation, the base for those tools is essentially a
graph execution engine working on the AST and it could very well be used
to produce a code generator (or backend) if that hasn't been done
already.
> If GNU were to match this, the work would go into tools based on GCC.
> The Emacs integration should be rather simple, since we are basically
> just calling a few external commands to have all the work done.
The plugin interface to GCC already exists and is apparently capable
enough to allow the implementation of a full AST dump. In fact it seems
that is already implemented in GCC MELT and other GCC plugins certainly
also have the depth to do this. One step further, DragonEgg
specifically implements a backend (using LLVM tools) that uses GCC as a
front end only, so I guess the only open question is whether or not that
back-end is free or non-free.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, Eric Ludlam, 2015/01/09
- Re: Emacs contributions, C and Lisp, David Engster, 2015/01/10
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/10
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2015/01/10
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2015/01/10
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/11
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/07
- Re: Emacs contributions, C and Lisp, Mario Lang, 2015/01/11
- Re: Emacs contributions, C and Lisp, Óscar Fuentes, 2015/01/11
- Re: Emacs contributions, C and Lisp, Mario Lang, 2015/01/11
- Re: Emacs contributions, C and Lisp,
Achim Gratz <=
- Re: Emacs contributions, C and Lisp, David Engster, 2015/01/11
- Re: Emacs contributions, C and Lisp, Helmut Eller, 2015/01/12
- Re: Emacs contributions, C and Lisp, David Engster, 2015/01/12
- Re: Emacs contributions, C and Lisp, Helmut Eller, 2015/01/12
- Re: Emacs contributions, C and Lisp, David Engster, 2015/01/12
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/11
Re: Emacs contributions, C and Lisp, Jacob Bachmeyer, 2015/01/10