Hi James, Questions like this are better directed to the v8-dev mailing list.
What is the relationship between Assignment and Declaration? The source > hints to me that Assignment actually knows whether it is a declaration or > not, and "var x = 0" would be considered an Assignment (whose parent would > likely be an ExpressionStatement). The separation between assignments and > declarations makes sense when keeping hoisting in mind, but I'm confused > because I'm used to thinking that declarations are statements (in ast.h > they derive directly from AstNode). > There's no direct relationship. In 'var x = 0', the 'var x' part is hoisted as a var declaration and the 'x = 0' remains an assignment, with a special internal '=' operator that indicates an initializing assignment. > > At a glance, some of the node types appear somewhat redundant. For > example, CountOperation looks like it could be adequately described by > UnaryOperation and the same is true for CompareOperation and > BinaryOperation. Are these extra nodes (CountOperation and > CompareOperation) defined solely for the compilation stage? > The AST is not as abstract as possible. It pretty closely follows the grammar in the ES3 spec. It turns out that it doesn't make much difference to us internally---there aren't really a lot of places where we want to treat count operations and the other unary operations uniformly, so it's more or less a matter of taste whether we dispatch on the node type or the operator. So: it's ad hoc, but not a pain point. > > Why is Throw defined as an expression and not a statement? > Because we translate some expressions that signal an error at runtime into 'throw <something>'. For instance, assignments with invalid left hand sides signal a reference error at runtime. Clearly, we could have chosen to use a special internal expression type as well. > > How is a try-catch-finally statement represented? I'm also curious as to > why TryCatchStatement and TryFinallyStatement exist, as opposed to having > TryStatement encompass all cases. > Well, try/finally and try/catch are handled differently (they're compiled differently, one introduces a scope the other does not, etc.). It simpler internally to have two completely different orthogonal constructs and to macro express try/catch/finally. The way you suggest will probably lead to code that has to detect three possibilities (try/catch, try/finally, and try/catch/finally) and handle them each slightly differently. > > Some insight would be much appreciated. > It's an ad hoc internal data structure. It does what it's asked :) > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
