2010/2/27 Robert Bowdidge <bowdi...@google.com>: > > On Feb 26, 2010, at 3:32 PM, Mike Samuel wrote: >> >> Caja doesn't do much normalization. We check that identifiers are >> unicode normalized according to NFC, and some passes will fail with an >> internal error if there are with(...) statements in the tree. > > For us, we've been informally moving to a normalized tree because many of > the complex optimizations - function inlining or control flow analysis - > become a lot easier when the tree's been simplified. We're treating the > normalized JavaScript in the same way a traditional compiler uses three > address code or static single assignment to simplify optimizations. > Unfortunately, we don't have a spec on that tree; our expectations on that > tree change quickly and vary by pass, so it's probably hard to be able to > specify exactly what a tree representation coming from elsewhere would need > to look like.
Ok, isn't this orthogonal to whether the wire format is JS source or some other system. If we hand around raw JS source, don't we need to hand around JS source that parses to a normalized form? > To get around the normalization issues, maybe we should instead hand around > either raw source (with a Closure Inspector source map) or a simplified > parse tree (maybe based on Rhino's parse trees coming out of the parser). > If you wanted to use the Closure Compiler "inline functions" pass, you > could get your AST out, then run it through the Closure Compiler > normalization and any other passes you want, and then either write out > another simplified AST or pretty-print the resulting tree back out to > JavaScript or into the base tree format. You'd still require some expert > knowledge to understand what normalizations are expected of any particular > pass, though if we don't document that already, perhaps we should. I think documenting the norrmalizations would be great. By normalizing to a three address code do you mean that something like x += y++ turns into var tmp0, tmp1; tmp0 = +y, y = tmp0 + 1, tmp1 = x + tmp0, x = tmp1 > Types could be handled by annotating the source or the tree, much as Closure > Compiler does now. > > I actually like the idea of printing code back out to source and keeping a > source map. Pretty-printed JavaScript code is a simple representation that > can't have compatibility problems, and allows each compiler to do whatever > normalization is needed. Also, we've been interested in passing the > generated code through the compiler multiple times for an internal project. > Being able to transform the source map from original code to derived code > 1, then from derived code 1 to derived code 2, and still preserving the > mappings back to the original source would be really helpful. Would a source mapping like lavabug's work? > Robert > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
