Repository navigation
It would be great if the AST format would follow the de facto JS standard #2
Description
The standard is informally maintained here:
https://github.com/estree/estree
The standard is informally maintained here:
https://github.com/estree/estree
Activity
daejunpark commentedon May 20, 2015
Could you please explain any use case in mind?
cos commentedon May 20, 2015
entree (i.e., Mozilla Parser API) is the de facto standard for JavaScript parsers. There are several high-performance, widely-used parsers implementing the API: esprima, espree, acorn, etc.
Following the same format would, on the one hand, allow the K parser to be used as a parser for various JS tools, and, on the other hand, it would allow us to use any of those parsers for parsing JS programs almost without compatibility issues.
Why would you care about the latter? You could, for example, compile the KJS to a K JS rewriter and then deploy the compiled rewriter to a web site. You wouldn't need the entire K infrastructure as the rules are already in AST format, and any program inputs would be parsed using one of the fast pure JS parsers.
cos commentedon May 20, 2015
Bottom line, if we want to have any chance of adoption of K in the JS world, we would need to follow their standards, and be able to run in a pure JS mode.
daejunpark commentedon May 21, 2015
Indeed, I was thinking of using Shift parser:
https://github.com/shapesecurity/shift-parser-js
To my knowledge, it is the most complete parser for ES6:
https://esdiscuss.org/topic/parser-for-es6
Its AST is similar with the one you mentioned, and they have a bidirectional converter as well.
BTW, what do you mean by compiling to K JS rewriter? Do you mean using the term rewriting engine written in JS that you mentioned before? Could you elaborate it more?