Langcc: A Next-Generation Compiler Compiler
I have not published any papers on parsing, but I&#x27;ve read a large chunk of the Handbook on Parsing, am buddies with Terrence Parr and have given a lecture on the ALL(<i>) parsing algorithm, and worked for a company that has perhaps the most extensive collection of GLR parsers around. (Whereas langcc boasts automatically-generated parsers for the easy-to-parse Python and Go, my old employer has automatically-generated parsers for Ruby, C++, COBOL, and about 100 others.) I would not consider myself an expert on parsing in comparison to the few who research it, but I would consider myself expert by the standards of most professional compiler engineers, and certainly by the standards of the average software engineer.<p>When I see a library like this, I ask &quot;What new things does this thing bring to the table?&quot; For that, before I even get into trying to understand what it does, I want to see how well the author understands what&#x27;s already been done and how it compares to prior work.<p>My very blunt assessment: I don&#x27;t see any reason to take this library seriously.<p>I looked at the 40 page paper. I can tell just from the citations that it takes a very 70&#x27;s few of parsing. And when it does discuss other work, it mostly gets it wrong. A few examples:<p></i> Page 8: He writes about the &quot;ETL family, also called GLR parsing.&quot; &quot;ETL family&quot; seems to be a term of his own coinage, and he&#x27;s writing about GLR parsing and Earley parsing as if they&#x27;re the same. Now that I think about it, I see some resemblance, but they&#x27;re usually considered quite different. See e.g.: <a href="https:&#x2F;&#x2F;cstheory.stackexchange.com&#x2F;questions&#x2F;30903&#x2F;why-tomita-created-glr-and-didnt-use-earley" rel="nofollow">https:&#x2F;&#x2F;cstheory.stackexchange.com&#x2F;questions&#x2F;30903&#x2F;why-tomit...</a><p>* Page 9<p>&gt; There has also been significant development of the top-down family of parser generators, including tools such as ANTLR [PQ95] which support a superset of LL(k) grammars, as well as their
parallel counterparts, referred to as Generalized LL (GLL). For the reasons described above, we
believe that while top-down parsers are theoretically interesting, the grammars they support are
not sufficiently general to capture full programming languages.6 Notably, they are significantly
more restrictive than LR(k), and we argue that even the latter is not sufficiently general in its
standard formulation.<p>This has not been true since ANTLR 2, released 25 years ago. The LL(<i>) algorithm of ANTLR 3, described in a 2011 publication, is capable of parsing even some context-sensitive grammars.<p></i> Page 9:<p>&gt; The tree automata of Adams and Might [AM17] are similar to our
implementation of monotonic attributes; they differ in that they impose left-to-right sequencing on the attribute constraints (whereas attributes can refer to arbitrary constituents of a grammar rule), and require productions to be duplicated (whereas attributes are boolean or integer values
layered independently on top of the standard context-free grammar rules).&quot;<p>This is one of my favorite papers of the last 5 years, and this is totally inaccurate. The user writes down a normal grammar and syntactic regular expressions for forbidden subterms. From that, it automatically generates a new grammar that e.g.: breaks symmetries.<p>In short, I think the author has the knowledge to claim that his solution beats the best that the 70&#x27;s and 80&#x27;s has to offer. I am not motivated to look at this any further because I&#x27;ve been given no reason to believe it&#x27;s had a fair comparison to what the 2010&#x27;s has to offer. I continue to recommend ANTLR 4 for your parser-generator needs. Its ALL(*) algorithm truly is magic. tree-sitter is also good and has a lot of momentum.<p>Joe Zimmerman: If you&#x27;re reading this, please don&#x27;t take it too personally. I&#x27;m reacting to the claims of the work more than the work itself. If you&#x27;d like, I&#x27;ll gladly discuss this with you. Either I&#x27;ll learn something new, you&#x27;ll get better at clarifying your ideas, or both.