Prematurely announcing ES-Lab (was: quasi-literal strawman)

# Mark S. Miller (16 years ago)

On Wed, Dec 23, 2009 at 10:45 AM, Kevin Curtis <kevinc1846 at googlemail.com>wrote:

The JsonML AST was a half-baked go at 'scheme by the backdoor'. (Though I muddied the water with the idea of using JsonML as a transport protocol. Doh.).

The strawman has been updated with an 'ast' entry: strawman:ast

Funny you should mention that. At ES-Lab code.google.com/p/es-lab, Tom

Van Cutsem and I have been defining a JsonML-based representation of ES5 ASTs. Now seems as good a time as any to announce it. See < code.google.com/p/es-lab/wiki/JsonMLASTFormat>. A playground for

seeing what ASTs are produced from parsing ES5 source texts is at < es-lab.googlecode.com/svn/trunk/site/esparser/index.html>. A

half-written ES5 meta-interpreter driven by these ASTs is at < code.google.com/p/es-lab/source/browse/trunk/src/eval/eval.js>.

For us, the immediate big payoff for these ASTs is the ability to write the simple verifier needed by the partial SES implementation at < code.google.com/p/es-lab/source/browse/trunk/src/#src/ses>. Please

keep in mind that all this is still a work in progress. However, the SES work has already gotten far enough along that I'm convinced that, given a parser->AST and an identity-hashtable, all the rest of the SES proposed by

those files can be implemented in a SES-compatible ES5[*] with

  1. a small download
  2. no blacklisting
  3. no runtime whitelisting
  4. no runtime overhead, aside from a eval, Function, RegExp.prototype.test, RegExp.prototype.exec and a quick initialization.
  • In an ES5 meeting the conditions stated at the top of initSES.js. Since we have not yet gotten our hands on any complete ES5 implementations, we don't yet know how realistic this is.
# Andy Chu (16 years ago)

Funny you should mention that. At ES-Lab code.google.com/p/es-lab, Tom Van Cutsem and I have been defining a JsonML-based representation of ES5 ASTs. Now seems as good a time as any to announce it. See code.google.com/p/es-lab/wiki/JsonMLASTFormat. A playground for seeing what ASTs are produced from parsing ES5 source texts is at es-lab.googlecode.com/svn/trunk/site/esparser/index.html. A half-written ES5 meta-interpreter driven by these ASTs is at code.google.com/p/es-lab/source/browse/trunk/src/eval/eval.js.

Possibly related: I have made Brendan Eich's Narcissus meta-interpreter into a CommonJS module, and it can be run on Narwhal.

andychu/narcissus

Since I think ES5 adds no new syntax over ES3.1, this should be an ES5 parser (?)

Here is an example of the JSON parse tree generated from json-template.js (a template language in 800-ish lines of code)

andychu/narcissus/raw/master/codegen/json-template.json

Yes, it's big. So I understand why people are using more compact array-based JSON formats.

There are some notes about the status in the README. The idea was to write some tools to process JavaScript code using this parser. It's rough, but working, so if anyone wants to use it let me know.

Andy