<div class="gmail_quote">On Thu, Jul 19, 2012 at 1:36 AM, Ronan Keryell <span dir="ltr"><<a href="mailto:Ronan.Keryell@wild-systems.com" target="_blank">Ronan.Keryell@wild-systems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>>>> On Wed, 18 Jul 2012 15:22:46 -0700, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> said:<br>
<br>
    Richard> Since you said you're performing source to source<br>
    Richard> transformations, AST transformation is unlikely to be a<br>
    Richard> good path to follow. A source to source transformation tool<br>
    Richard> should usually make very targeted modifications to the<br>
    Richard> code, and it's not really practical to deduce what those<br>
    Richard> changes should have been if all you have are ASTs from<br>
    Richard> before and after (think about preserving whitespace,<br>
    Richard> comments, macros, templates, ...).<br>
<br>
It depends on what you want to do with source-to-source transformation.<br>
<br>
If for example I use source-to-source transformations to generate from a<br>
sequential C/C++ program a parallel program with multiple processes<br>
communicating with MPI, with OpenMP #pragma on each SMP node with some<br>
calls to SIMD intrinsics and some parts in CUDA or OpenCL to address<br>
heterogeneous computing, a simple textual transformation is just NOT a<br>
good path to follow.<br>
<br>
Another typical use case is high-level hardware synthesis from C/C++.<br></blockquote><div><br></div><div>Right, if you're generating input to another tool, emitting output from a parsed AST is completely reasonable. My message was mostly concerning tools whose output is supposed to be maintained by a human; apologies for not making that clear.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    Richard> The usual approach for clang-based source-to-source<br>
    Richard> transformation tools is to use the AST to determine what<br>
    Richard> changes should be made, then produce a list of<br>
    Richard> modifications to be made to the original source file. See<br>
    Richard> clang::Rewriter, clang::tooling::Replacement, and<br>
    Richard> clang::tooling::RefactoringTool for some components which<br>
    Richard> make it easier to build such tools.<br>
<br>
Yes, but some people are interested by a less "usual approach". :-)<br>
For serious things, AST transformations are the only way to go.<br>
<br>
Keeping track of comments in the AST is a first step, even if<br>
source-to-source transformations are intractable in the general case<br>
because you need to keep the semantics of... comments. I do not even<br>
talk about macros...<br>
<br>
Just imagine how to translate<br>
/* ... */<br>
/* ... */ a/*  */<br>
    +=<br>
  /* ... */b  /* ... */<br>
 ; //...<br>
<br>
to<br>
a = a + b;<br>
<br>
Where do you want to keep/duplicate the comments ? You have to<br>
"understand" them to resynthesize their new layout and content. :-(<br>
<br>
Even with simpler cases it is already a nightmare...<br></blockquote><div><br></div><div>Exactly; this is one reason why AST to AST transformations for such cases are problematic. If your output is a list of source transformations, though, it's easy to produce</div>
<div><br></div><div>/* ... */<br>/* ... */ a/*  */<br>    = a +<br>  /* ... */b  /* ... */<br> ; //...<br></div><div><br></div><div>or</div><div><br></div><div><div>/* ... */<br>/* ... */ a/*  */<br>    =<br>  /* ... */a + b  /* ... */<br>
 ; //...<br></div></div><div><br></div><div>as you prefer.</div></div>