Arc Forumnew | comments | leaders | submitlogin
3 points by rocketnia 3606 days ago | link | parent

I recommend using the UglifyJS JavaScript parser, which exposes a well-documented AST: http://lisperator.net/uglifyjs/ast

---

"It's the kind of takeover any language could do to any other"

JavaScript's a big language. It comes standard with complex (and I'd say quirky) systems for floating point numbers, date handling, and regexes. ECMAScript 5's strict mode repurposes the same JavaScript syntaxes for slightly different semantics, fracturing the language even within the same spec. That spec also defines at least three different ways of interpreting a JS string as JS code, if we count eval(), strict mode eval(), and the Function() constructor.

The standard is just one small glimpse of the landscape of JavaScript compatibility:

The language is commonly split into intentionally different dialects. The HTML spec willfully violates the ECMAScript spec so that document.all can be falsy[1]. Mozilla's asm.js repurposes the same JavaScript syntaxes to have substantially different performance when they're used a certain way. And of course there are proper extensions and variations of the language, like TypeScript, Harmony, Mozilla's own line of JavaScript versions, the JavaScript-inspired UnityScript and ActionScript, etc.

Nonstandard features are frequently needed. Different JavaScript platforms like the HTML spec, Node.js, Rhino, RingoJS, and Windows Script Host add (or don't add) their own varying tools for concurrency, sandboxing, error handling, debugging, global scope management, package distribution, and module imports, which tempts even general-purpose library writers to stray from standards. Meanwhile, JavaScript libraries sometimes silently take advantage of widespread but underspecified features such as function names, function toString() representations, object.__proto__, and object key iteration order.

Given all this, the good news is that a translator from JavaScript can't be expected to have 100% compatibility. Like Caja, the Clojure Compiler, and Browserify, it may have to put quirky limits on the subset of JS code it intuitively supports. One place to look for a not-so-quirky subset might be lambdaJS[2], which has been used for formal correctness checking.

[1] http://stackoverflow.com/questions/10350142/why-is-document-...

[2] http://blog.brownplt.org/2012/06/04/lambdajs-coq.html