> > Why should the backend have to deal with JS AST nodes?
I'm considering changing the emit phase to produce a Google Closure Compiler AST. This would have several benefits: 1. The emit phase would become functional (returning an AST) instead of procedural (printing source). 2. Test porting a few emit methods shows a pretty significant decrease in branching, ordering-complexity, etc. 3. Performance: Minification and optimization could occur directly on the AST, without having to print & re-parse the JavaScript. 4. SourceMaps would be provided, virtually for free, by the Closure Compiler. We just need to copy line and column metadata to the JS AST nodes. 5. Pretty printed code generation is also free (useful for debugging the compiler). Downsides: 1. There isn't an obvious way for the js* form to work as it does now (with strings), but it could work with AST output. 2. This would more strongly couple us to the Closure Compiler (although the AST building interface<http://code.google.com/p/closure-compiler/source/browse/trunk/src/com/google/javascript/rhino/IR.java> is pretty simple and functional, so could be replaced). 3. Pretty risky change to rework the entire emit phase. This idea was inspired by CoffeeScriptRedux<https://github.com/michaelficarra/CoffeeScriptRedux>'s use of escodegen <https://github.com/Constellation/escodegen>. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
