<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">On Mon, Aug 13, 2012 at 4:36 AM, João Matos <span dir="ltr"><<a href="mailto:ripzonetriton@gmail.com" target="_blank" class="cremed">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>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>