Arc Forumnew | comments | leaders | submitlogin
A Javascript parser in Arc?
4 points by lark 3594 days ago | 1 comment
I'm wondering if anyone knows of a Javascript parser in Arc. Or at least, a Javascript parser that can be easily modified to add an Arc backend to it: to have it generate Arc.

I would like to take existing Javascript libraries and convert them into Arc. The reason to want to do that is so you can write web applications that need to execute client-side code, but to write this code in Arc, not in Javascript.

I'm aware of the irony involved here. You start as a language that serves the web in plain HTML. Then write an Arc interpreter in Javascript. You automatically port Javascript libs in Arc. Arc takes over. It's the kind of takeover any language could do to any other, like a virus spreading in a host. There's also no end to how far you could stretch these mutations. You could even automatically generate Arc interpreters for any language if you wanted to.

(Or an admittedly perverse meta-programming example: to generate any interpreter for any language written in any language.)

The biggest obstacle in this exercise is the effort involved. It'd be painful to write a parser in C for example. But is it really that much effort to write a Javascript parser with a Lisp?



3 points by rocketnia 3594 days ago | link

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

-----