<div dir="ltr">On Sun, Feb 24, 2013 at 11:59 AM, Joshua Cranmer <span dir="ltr"><<a href="mailto:pidgeot18@gmail.com" target="_blank">pidgeot18@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2/24/2013 5:38 AM, Markus Elfring wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can't say that I can think of a single time where I would ever want the raw parsed AST with no semantic analysis done on it.<br>
</blockquote>
<br>
Are you interested in detailed source code transformations after a specific analysis on a control flow graph?<br>
Do you see use cases to drill down from higher abstraction levels to the abstract syntax tree to generate some adjustments?<br>
</blockquote>
<br></div>
The short answer here is "no", because viewing refactorings as transformations on ASTs is wrong. Refactoring is really transforming source text to source text guided by high-level semantic rules; treating it as AST implementations will cause lots of grief when you try to reserialize that AST, thanks in large part to the complications of macros and templates (macros++).<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How do you think about consequences and challenges like they are demonstrated by the semantic patch language from the software "Coccinelle"?<br>
<a href="http://coccinelle.lip6.fr/sp.php" target="_blank">http://coccinelle.lip6.fr/sp.<u></u>php</a><br>
</blockquote>
<br></div>
Semantic patching is very seductive, but it's a poor substitute when it comes to complicated refactorings. The use case I played with a few years ago was rewriting a C API into C++, which requires some semantic rules cumbersome to produce in an spatch-like format. The best example I have is "make the first argument to be 'derived' from MimeObject be the implicit this argument." Another one is "every object which is the implicit this argument cast to some other type is really just the implicit this argument, if the cast is a cast to the current class type or some superclass thereof".</blockquote>
<div><br></div><div style>And the clang AST actually works fine for building tools like that on top - we're doing similar stuff on a daily basis based on the AST matchers and Tooling/Refactoring libs. </div><div style>
<br></div><div style>If anybody really wanted to spend some time "fixing" the AST, I'd suggest to look at how to introduce an ExpressionStatement instead of having all Expressions be Statements :)</div><div style>
<br></div><div style>Cheers,</div><div style>/Manuel</div></div></div></div>