batiste
Feature Request: PEG.js compatible/similar/resembling grammar definition DSL
Congratulations, a very nice project! Well done. The only thing which made me crazy is that the grammar definitions are in JSON format. Well, to be honest, nobody actually wants to write their grammars this way. If you would add an optional DSL to JSON parser (itself implemented with EPEG.js, of course!) which accepts a PEG.js compatible/resembling DSL and outputs your EPEG.js JSON format, this would be even more phantastic.
var dslDef = "...the PEG.js grammar DSL read from an external file...";
var grammarDef = EPEG.compileGrammarDSL(dslDef);
var parser = EPEG.compileGrammar(grammarDef, tokensDef);
Because of the possible action rules in JavaScript it might be complicated this way (as the JavaScript code would have to be represented as text in dslDef which is nasty), a direct step would be also just fine:
var dslDef = "...the PEG.js grammar DSL read from an external file...";
var parser = EPEG.compileGrammarDSL(dslDef);
This would give your project another boost, I think. Because PEG.js is really THE parser generator for JavaScript. A PEG.js compatible or at least very similar grammar DSL is a major acceptance criteria IMHO...
"Well, to be honest, nobody actually wants to write their grammars this way"
http://www.reddit.com/r/javascript/comments/2pzn4k/epegjs_an_easy_to_use_javascript_grammar_parser/cn2d1mo
There is already 1 person plus me so we are 2. Trust me there is nothing crazy about using JavaScript to describe a grammar. I am trying to do better than pegjs as I am unsatisfied with it. I am not sure copying their weird grammar def is a good idea.
You might be familiar with pegjs format but for anybody new to it there is nothing intuitive about it. It's mixing some weird DSL with JavaScript when JS would be sufficient. For me this is the crazy part: the DSL is more confusing than just plain JS although I would admit it's a little bit less verbose.
And then I am not even going into the field of how pegjs is working internally. It's using code generation, evals and add an extra compilation step which is never desirable. The only viable reason I can see for it is potential better performance.
EPEG.js doesn't use any of those tricks. There is no code generation, no eval, and the hooks/ functions are just plain JS function that have access to the local scope which is great. The more I think about it the more I think EPEG.js is doing the right thing.
Having said that I am still interested about the idea. And it could be a good showcase for the EPEG.js to have such a language.
Well, yes, from a plain design perspective your "do everything in just plain JavaScript" is a decent and very clean approach, of course. I fully agree. OTOH writing grammars also has to be "funny enough" (aka: you have to be able to master the overall complexity) and here IMHO conciseness usually is key. An external DSL can help here. And it really should be just optional, of course. And, yes, an "eat your own dogfood" style showcase is another nice reason why one wants such a DSL for the grammar definition.
One more note: there could be also a conciseness approach somewhere between the external DSL and the internal JSON: Sweet.js macros which transpile a less verbose JSON variant to the regular JSON. I've recently used Sweet.js for a similar job and it worked just fine for me. I've used it even in a way where all .js files in a Node.js application were automatically on-the-fly transpiled via Sweet.js, so there was not even a need for a separate build/generator step...
You have now a language that can be used to generate the grammar:
https://github.com/batiste/EPEG.js/blob/master/grammar.txt