It would be great if the AST format would follow the de facto JS standard

[cos]

The standard is informally maintained here:
https://github.com/estree/estree

[daejunpark]

Could you please explain any use case in mind?

[cos]

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]

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]

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?