[cfe-dev] about AST of clang

[Ronan Keryell]

>>>>> On Sat, 21 Apr 2012 10:29:58 +0200, Manuel Klimek <klimek at google.com> said:

    Manuel> As I said before, I might not understand what you're trying
    Manuel> to do.  That said, I think that changing the code is a
    Manuel> superset of changing the AST, so I don't understand why it's
    Manuel> harder to do certain things that way. It of course requires
    Manuel> a very precise mapping of AST nodes to source code, which
    Manuel> clang luckily enough has. It also requires that you still
    Manuel> want to do C++ (if you don't, that would be a case where
    Manuel> what I say clarly does not apply).

My argumentation is that if the Clang front-end is used more and more as
a generic source-to-source translator, at some point we will need some
features helping the programmers to do so.

For example, just think to generating code for some kind of
heterogeneous accelerators, for example GPU. You need to outline some
pieces of code to new functions and it is quite complicated to do it in
the general case at the source level. Even at the AST level with more
suitable abstractions it is already difficult, as we can see in other
source-to-source compilers (as with ROSE Compiler & PIPS I know)

    Manuel> As for changes of internal representation getting in your
    Manuel> way - how's that better when you directly work on the AST -
    Manuel> on the contrary, I expect subtle changes to the invariants
    Manuel> of the AST to make it much harder to still produce correct
    Manuel> ASTs by shoving around AST nodes, instead of making textual
    Manuel> changes.

That is true. But for quite complex transformation work, I'm not sure
there is another way...

    Manuel> And third, if you ever want the changes to go back to the
    Manuel> programmer in code form, you suddenly need to care about
    Manuel> formatting etc, and minimally disruptive changes to the
    Manuel> text.

Of course, I assume in the "higher level" support that we need, we keep
information on all the formatting stuff. :-)

But anyway, it is an intractable issue per se (transformation on code
with a macro expansion, what is the very semantics of a comment
envisioned by the programmer at some position in the code...), but we can
provide some support for simple cases.

    Manuel> I don't understand yet why you think the direct tree
    Manuel> transformation is per se cleaner.

Because at some point of transformation complexity, it is cleaner to
invest in some common high-end source-to-source transformation support
and rely on it to develop all the complex tools, rather than trying to
do too complex stuff with string transformations.

But it is related to what we expect to do with the tool and it may not
apply to you. I understand it may not be the mainstream use for
Clang. :-) For some of our use cases (not using Clang), have a look to
par4all.org for example.
-- 
  Ronan KERYELL                            |\/  Phone:  +1 408 658 9453
  Wild Systems / HPC Project               |/)
  5201 Great America Parkway, Suite 320    K    Ronan.Keryell at wild-systems.com
  Santa Clara, CA 95054                    |\   skype:keryell
  USA                                      | \  http://wild-systems.com