The goal of
jspeg is to provide a modern PEG environment for contemporary
What is a Parsing Expression Grammar?
Parsers Are Hard ™.
There are lots of ways to go about writing parsers:
- LL, LR, LALR
- Recursive descent, Pratt
- Earley, Combinator
- Et cetera
Lots of these have advantages and disadvantages. Some are faster; some can't express certain languages; some need more computer resources; some are easier; and so on. Mostly these are trade-offs; the fast one is the difficult one, et cetera. (Of course they are; if one parser won on all metrics, that'd be the one everyone used.)
Why choose PEGs in general?
PEGs strike a pretty good balance:
- They're comparatively easy to write and maintain
- They usually give great error messages
- Their resource use isn't huge, though they're a little RAM hungry
- They're a little above-average in speed, even on large documents
- They can conveniently express most languages
PEGs are a fairly middle of the road choice. They're good-ish for most things.
Why choose JsPeg?
The library this library descends from, peg.js, did a remarkably good job of finding this balance, and providing stable, reliable tooling to do real world work.
As such, a fork was required.
JsPeg is a modernization. It's sort of a fork - the github repo is not inherited; only the code. The code has been static for half a decade; cutting the history away, and the tooling around it built for hosting that doesn't exist anymore should be discarded wholesale.
In the meantime, some of
peg.js' most productive features, such as its IDE,
should be re-written in modern tooling, like embedded
But the parser generator?
It's a gem. Let's save it. All your grammars should be maintained.
It's not a new
peg engine you know, love, and use, re-tooled for a modern world.