by charlieirish on 2/8/25, 1:15 PM with 43 comments
by Cadwhisker on 2/12/25, 3:49 AM
PEGs are extremely difficult to debug when things go wrong because you get a MASSIVE trace (if you're lucky) to sift through. This tool has rewind/playback controls to dig into what the PEG rules are doing.
Previously, the best I'd seen was cpp-peglib's online parser, here: https://yhirose.github.io/cpp-peglib/
Edit: and now having read through comments here, Chevrotain's PEG tool looks really impressive, although it doesn't use a simple PEG syntax for the input: https://chevrotain.io/playground/
by vanderZwan on 2/12/25, 2:38 PM
I'm mentioning it because it implements a toy language using Ohm to explain how WebAssembly works (gee wonder why). So it actually includes a mini-Ohm tutorial.
Funny enough, since WASM bytecode is designed to be compact, and speccing out parsers tends to be a more verbose business, the book technically ends up spending more words on implementing the parser than on WASM itself (all with the goal of developing a mental model for WASM though, which it succeeded at for me so this is not a critique).
by nhatcher on 2/12/25, 10:20 AM
I am a big fan of PEG parsers. They do come with their set issues and difficulties but I always found them great to work with. My to go tool (also a PEG parser similar to Ohm) used to be pegjs now https://peggyjs.org/
When I needed speed, or a more classical take, I would use jison. But I think today I would have to find a good reason not to build a hand made parser.
by fovc on 2/12/25, 1:15 AM
by mhitza on 2/11/25, 11:34 PM
I've only used PEG once because of builtin support in Guile scheme, but this library might be a bit more useful, as it's in JS.
by jitl on 2/12/25, 2:54 AM
by skybrian on 2/12/25, 3:48 PM
One thing I think it sheds light on is the difference between a simple library and a framework. Many frameworks can be thought of as providing an interpreter that you configure using callbacks. Debugging a high-level program by stepping through the interpreter that's executing it isn't easy. Custom debugging tools make it easier.
by jbreckmckye on 2/12/25, 1:46 PM
by patrickthebold on 2/11/25, 11:24 PM
by fjfaase on 2/12/25, 7:25 AM
Can you also specify color coding for your grammar?
This is a parser generator. In the online editor, even with the example grammar, you can see that there is some delay when you change the grammar in what is being parsed. I wrote an interactive back-tracking parser with caching that does not show less delay with a bit larger grammar. Search for 'IParse Studio'.
by deostroll on 2/12/25, 10:58 AM
Oh, and comments!!! My general observation is that one cannot capture the comments when code is generated from ast. Although esprima has something in the standard to this effect, implementations generally stuck with weird commenting styles and how to generate code from them...for e.g
var /* hello */ world, foo, /* bar */ s;
by incrudible on 2/12/25, 1:47 PM
by lukasb on 2/12/25, 12:43 AM
by derhuerst on 2/12/25, 1:58 PM
by RickS on 2/11/25, 11:38 PM
For anybody already using this, what's your workflow like for getting from this to IDE syntax highlighting?
by gr4vityWall on 2/12/25, 2:36 PM
by phfrohring on 2/11/25, 11:24 PM
by doug_life on 2/12/25, 3:08 AM