Ohm’s key selling point for me is the visual editor environment, which shows how the parser is executing on various sample inputs as you modify the grammar. It makes writing parsers fun rather than tedious. One of the best applications of “live programming” I’ve seen.<p><a href="https://ohmlang.github.io/editor/" rel="nofollow">https://ohmlang.github.io/editor/</a>
I'm so happy to see this on HN. I've used Ohm for several projects. If you want a tutorial for building a simple programming language using Ohm, check out this series I put on GitHub.<p><a href="https://github.com/joshmarinacci/meowlang" rel="nofollow">https://github.com/joshmarinacci/meowlang</a>
Compiler compilers are great, I love writing DSLs for my projects. I usually use yacc/lex, or write my own compiler (typically in go these days).<p>However (and this is just me talking), I don't see the point in a javascript-based compiler. Surely any file format/DSL/programming language you write will be parsed server-side?
This is an example of a library we built using Ohm: <a href="https://github.com/Bridgeconn/usfm-grammar" rel="nofollow">https://github.com/Bridgeconn/usfm-grammar</a> [1]<p>It works great for our use-case though I have been eyeing tree-sitter[2] for its ability to do partial parses.<p>[1] USFM: <a href="https://ubsicap.github.io/usfm/" rel="nofollow">https://ubsicap.github.io/usfm/</a>
[2] <a href="https://tree-sitter.github.io/tree-sitter/" rel="nofollow">https://tree-sitter.github.io/tree-sitter/</a>
This is a follow-up to a major component of the <a href="http://vpri.org/writings.php" rel="nofollow">http://vpri.org/writings.php</a> project that created an self-contained office suite, OS and compiler suite in something like 100-200k lines of code without external dependencies.
Each PEG generator promises a revolution but only burns a car.<p>I was disappointed with how they do operator precedence; they use the usual trick to make a PEG do operator precedence which looks cool when you apply it to two levels of precedence but if tried to implement C or Python in it it gets unwieldy. Most of your AST winds up being nodes that exist just to force precedence in your grammar, working with the AST is a mess.<p>For all the horrors of the Bell C compilers, having an explicit numeric precedence for operators was a feature in yacc that newer parser gens often don't have.<p>I worked out the math and it is totally possible to add a stage that adds the nodes to a PEG to make numeric precedence work and also delete the fake nodes from the parsed AST. Unparsing I'm not so sure of, since if someone wrote<p><pre><code> int a = (b + c);
</code></pre>
how badly you want to keep the parens is up to you; a system like that MUST have an unparse-parse identity in terms of 'value of the expression', but for sw eng automation you want to keep the text of the source code as stable as you can.
I've used PEGs in the past. They're nice since they combine the mental model of LL grammars with the automation of LALR parser generators. However, it is quite easy to accidentally write rules where you never parse the second rule due to the ordering priority for rules. For instance:<p><pre><code> ident ::= name | name ("." name)+
</code></pre>
Because with PEGs, the parser tries the first rule, then the second, and because whenever the second rule matches, the first one will also match, we will never parse the second rule. That's kinda annoying.<p>Of course with PEG tools you could probably solve this by computing the first sets for both rules and noticing that they're the same. Hopefully that's what this tool does.
I recently wrote a similar parser, maybe less fancy, for a workshop on parsing. It does display the the abstract syntax tree with d3.js and also has a build evaluator for a limited set of language constructs. <a href="https://fransfaase.github.io/ParserWorkshop/Online_inter_parser.html" rel="nofollow">https://fransfaase.github.io/ParserWorkshop/Online_inter_par...</a>
It is based on a parser I implemented in C++.
I’ve built a number of toy language projects with Ohm and it’s really wonderful. Just a joy to use the visual tooling also. All around really beautiful machinery
Always fun to find the first commit:<p><a href="https://github.com/harc/ohm/commit/4611bf63c5ecb90d782112d68f73a2277f87ca7d" rel="nofollow">https://github.com/harc/ohm/commit/4611bf63c5ecb90d782112d68...</a><p>2014<p>Neat tool. I write parsers by hand though. More fun, and you can be a lot sleazier.
We are using Ohmjs on a project at work and it is fantastic. I'm hoping one day that Ohmjs and Ohm/s (Squeak) can be compatible again -- would love to have the Smalltalk version of our interpreter and environment we built using this
I recently created a library for the other part of an interpreter.<p><a href="https://github.com/codr7/liblg" rel="nofollow">https://github.com/codr7/liblg</a><p><a href="https://github.com/codr7/liblgpp" rel="nofollow">https://github.com/codr7/liblgpp</a>
It'd be cool if the online editor dispensed with the need to "write the grammar" entirely. A node based parser-generator in addition to Ohm being yet another grammar based parser-generator would be pretty great.
OHM is also the acronym for Open Hardware Monitor, a great open-source project for monitoring computer temperatures, fan speeds, voltages, etc: <a href="https://openhardwaremonitor.org/" rel="nofollow">https://openhardwaremonitor.org/</a>