JavaScript Parser Generators that can be used with the Closure Compiler

2
votes

I've been looking at parser generators for Javascript and have a found a few (PEG.js, namely).

Whats not clear, though, is how well these would play with something like the Google Closure Compiler.

E.g, it looks like in PEG.js, I can give it code to execute as part of the rules, but how can I bind functions (that might be renamed by the compiler) to the rules?

Additionally, its unclear to me which parsers support passing in a symbol table. E.g, I want to define a grammar that accepts an expression like "A or B", where the value of "A" and "B" are defined at runtime, e.g., as attributes of a record a user is viewing.

PEG.js isn't a requirement of course, just the only parser generator that seems to turn up in search results and looks usable.

2
javascriptparser-generator
ANTLR can produce JavaScript source. Whether it plays with Google Closure Compiler, I have no idea of. I do know that there's much more possible with ANTLR than PEG.js (I like PEG.js a lot, don't get me wrong!). - Bart Kiers
Hm, does ANTLR require a build/compile stage? Preferably, I'd like to just include a .js file, define the grammar in JS, and be ready to go. - Richard Levasseur
Then ANTLR is not an option. With ANTLR you need to invoke the (Java class) org.antlr.Tool on your grammar to generate a parser. - Bart Kiers

2 Answers

1
votes

There are a few parsers with Javascript as output language listed here. For parser that are actually build in Javascript and can be used without pre-compilation in the browser, it seems that besides PEG.js there is JS/CC.

There are other ways, like sending a grammar to a parser generator on the server. For that there would be Jison (the site includes a demo of it) using Nodejs and probably other parsers written in other languages from the list above could run on your server too. If those generated files are compatible with the closure compiler, they could be compiled on the server, before sending the location of the generated parser back to the site. Maybe the parsers are already optimized and there wouldn't be much to do for the compiler, that should be checked first.

The server solution would mean that symbols aren't really defined at runtime, but that the grammar is defined at runtime and a parser can be generated for that grammar. That is quite a difference but may be just what you need. If you only need a symbol table which is used to check if identifiers exists or have the correct (static) type, it probably is enough to analyse the resulting parse tree and throw errors at that point.

0
votes

My AGL parser builder is written in Kotlin common, so it can be used on any Kotlin target (JVM, JavaScript, native code, etc).

const agl_module = require('net.akehurst.language-agl-processor');
const Agl = agl_module.net.akehurst.language.agl.processor.Agl;
const grammarStr = ...
const sentence = ...
const proc = Agl.processorFromString(grammarStr);
const asm = proc.process(sentence).toArray();

For full details see:

https://medium.com/@dr.david.h.akehurst/a-kotlin-multi-platform-parser-usable-from-a-jvm-or-javascript-59e870832a79