I agree with your reasoning from a semantic viewpoint, if we're not considering other use cases than code generation here. But the AST is being increasingly used in a lot more places than code generation, like for IDE support and refactoring, so it's a bit of tradeoff between syntax and semantic uses. In my experience it is much easier to consume this information for syntax purposes if it follows the syntax closely, instead of having to special case a lot of nodes that provide information in different ways.<div>

<br></div><div>I do have a question about this because I noticed lately a lot of nodes that do not provide locations for some syntactic elements. Should these be patched to provide them, or is it a goal for the AST tree nodes produced by the AST library to be kept as lightweight as possible and only suitable for semantic / code generation purposes? If so, should we provide another AST library that models nodes following syntax as close as possible?</div>

<div><div><div><div><div><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 9:36 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">Just to explain perhaps a bit more, as I too agree with Eli and Chad here...</div>

<div class="gmail_quote"><br></div><div class="gmail_quote"><div class="im">On Mon, Aug 13, 2012 at 4:36 AM, Joćo Matos <span dir="ltr"><<a href="mailto:ripzonetriton@gmail.com" target="_blank">ripzonetriton@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">I agree, it would be best to store one node per statement in the AST, even if semantically they will be handled as one.</div>


</blockquote><div><br></div></div><div>This is a pretty fundamental deviation from the model for the AST.</div><div><br></div><div>We have AST nodes to represent the structural semantics of the program. Many of these do not even correspond to syntax in the source program. They are there to expose the underlying semantics of the structure after parsing has taken place. The inverse applies here: even though there may be syntax recognized by the parser that resembles that of multiple statements, if the actual semantic model is that of a single statement, the AST should reflect that.</div>


<div><br></div><div>When you say "It would be best to store one node per statement in the AST" you are begging the question by assuming there are multiple statements in the source program. I think what Eli and Chad are arguing is that there is exactly one node per statement in the AST, and all of the inline asm instructions are part of a single statement due to their semantic model.</div>


<div><br></div><div>None of this should preclude us exposing source locations and other information about the syntax used to spell the collection of assembly instructions that goes into the statement. We have more tools available than just Stmt nodes in the AST. =]</div>


</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Joćo Matos<br>
</div></div></div></div></div>