Ohm: A user-friendly parsing toolkit for JavaScript and TypeScript

I&#x27;m particularly impressed with the visual PEG debugger tool, here: <a href="https:&#x2F;&#x2F;ohmjs.org&#x2F;editor" rel="nofollow">https:&#x2F;&#x2F;ohmjs.org&#x2F;editor</a><p>PEGs are extremely difficult to debug when things go wrong because you get a MASSIVE trace (if you&#x27;re lucky) to sift through. This tool has rewind&#x2F;playback controls to dig into what the PEG rules are doing.<p>Previously, the best I&#x27;d seen was cpp-peglib&#x27;s online parser, here: <a href="https:&#x2F;&#x2F;yhirose.github.io&#x2F;cpp-peglib&#x2F;" rel="nofollow">https:&#x2F;&#x2F;yhirose.github.io&#x2F;cpp-peglib&#x2F;</a><p>Edit: and now having read through comments here, Chevrotain&#x27;s PEG tool looks really impressive, although it doesn&#x27;t use a simple PEG syntax for the input: <a href="https:&#x2F;&#x2F;chevrotain.io&#x2F;playground&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chevrotain.io&#x2F;playground&#x2F;</a>

BTW, if you&#x27;re like me and have been wanting to target WASM bytecode directly for ages without any of the heavy existing toolchains, but unable to put the separate pieces of the spec together yourself: the core maintainer of this library is co-authoring a book for that[0]. I decided to take the risk of giving the early access version a try and it&#x27;s really nice and accessible.<p>I&#x27;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.<p>Funny enough, since WASM bytecode is designed to be compact, and speccing out parsers tends to be a more verbose business, the book <i>technically</i> 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).<p>[0] <a href="https:&#x2F;&#x2F;wasmgroundup.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wasmgroundup.com&#x2F;</a>

I am jealous of kids these days learning the theory of parsing. There are so many great resources out there! Ohm in particular looks great, attention to detail, care for the theory. Makes me wish I had a project to try it out.<p>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 <a href="https:&#x2F;&#x2F;peggyjs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peggyjs.org&#x2F;</a><p>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.

Great to see this is alive and progressing! I believe Ohm started life in Alan Kay’s research group, to build a graphical OS and office suite in 10k lines of code. I found this talk immensely inspiring <a href="https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?v=ubaX1Smg6pY" rel="nofollow">https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?v=ubaX1Smg6pY</a>

Can anyone familiar with PEG explain how much it deviates (&quot;inspired by&quot;) from &quot;standard&quot; PEG?<p>I&#x27;ve only used PEG once because of builtin support in Guile scheme, but this library might be a bit more useful, as it&#x27;s in JS.

Top thing I want to know about a parser&#x2F;parser generator library, is will it go fast? After a poor experience with Chevrotain startup performance I’m more open to parser-generators than parsers, I’m very happy to pay for a build step if my compiler will boot up faster (important in the browser) and have better throughout.

This looks very interesting, particularly the visualization tool.<p>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&#x27;s executing it isn&#x27;t easy. Custom debugging tools make it easier.

For an example usecase, the Bruno API client uses Ohm to parse its .bru API spec files<p><a href="https:&#x2F;&#x2F;github.com&#x2F;usebruno&#x2F;bruno">https:&#x2F;&#x2F;github.com&#x2F;usebruno&#x2F;bruno</a>

In the past, I had always had a distaste for &#x27;stringy&#x27; data, always preferring more structure (e.g objects). Once I learned about parsers, I realized you can still have structure in a string.

Looks quite nice. The online editor with color coding looks sleek. I suppose that they are using a PEG-parser to parse the grammar in the online editor.<p>Can you also specify color coding for your grammar?<p>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 &#x27;IParse Studio&#x27;.

Anybody out there who has tried to convert js to ast and back and got OOM?! (I tried @babel&#x2F;parser). I pray this one doesn&#x27;t disappoint.<p>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<p>var &#x2F;* hello *&#x2F; world, foo, &#x2F;* bar *&#x2F; s;

I have a rule that says: You are not allowed to use these tools until you have written a recursive descent parser yourself. Parsing manually is not that hard, but giving good errors while parsing automatically is not that easy.

Can anyone compare to Chevrotain?

remotely related: When I used nearley.js [0], it had a very good learning curve. Tooling also looks quite nice.<p>[0] <a href="https:&#x2F;&#x2F;nearley.js.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nearley.js.org&#x2F;</a>

Oh hell yeah. Stoked to see something like this in TS. I enjoy making a toy DSL here and there, but it&#x27;s a lot of friction to relearn Lex and Yacc every time. The editor looks great too, really like the visualizations.<p>For anybody already using this, what&#x27;s your workflow like for getting from this to IDE syntax highlighting?

My first impression is that the tutorial is exceptionally well-written. This project looks very interesting!

Great! Worth trying! I&#x27;ve built a parser for the robotic arm language (LCD 350) with it in record time.

Side note, I really wish software would stop using EE terminology to name things. Ohm, Capacitor, Electron, etc. It muddies up search results for no good reason. Is there a reason this has become a trend lately?