HN Reader

Development on Antlr4 has terminated. The "official ANTLR" successor, called Antlr5, was intended to enable ANTLR to run in a browser, replacing over a half-dozen runtime targets with a unified runtime target, and to add LSP services. But development on Antlr5 stopped after a few months, a year and a half ago, and I don't see when it'll be restarted, if ever.

Antlr-ng is Mike Lischke's port of Antlr4, which he likely undertook because ANTLR is used at Oracle for one MySQL product. It's not "official ANTLR," but Terence Parr granted him the use of the "ANTLR" name and allowed a fork to port the existing Antlr4 code to TypeScript.

Mike's Antlr-ng port of the Antlr4 code began with a Java-to-TypeScript translator he wrote. Along the way, he made some improvements to the TypeScript target.

But, Antlr-ng uses ALL(star). Therefore, it shares the same performance issues as Antlr4. I'm not sure where Mike wants to take Antlr-ng to address that issue.

ANTLR is presented as a generator for small, fast parsers. ALL(star) probably can't do that. Many grammars people write are pathological for ANTLR. People hand-write parsers, reverse-engineer the EBNF from the implementation as an afterthought, drop the critical semantic predicates from the EBNF, and then refactor it into something else—example: the Java Language Spec.

Has performance of ANTLR generated code gotten better? I'm sure some of this was bad grammars, but I wasn't thrilled with what I got out of ANTLR ~15 years ago

Is antlr particularly popular these days? I was under the impression that most production parsers are some kind of handwritten recursive descent parsers, primarily because they're better at providing diagnostics and can sometimes be easier to maintain.

I'm a fan of antlr-ng. It's a solid upgrade if you're already using antlr. In my experience, they're fully compatible. antlr's ALL(*) parsing is relatively powerful for a parser generator, but it lacks support for incremental parsing. antlr-ng might improve things enough to be usable interactively in smaller settings, even if you need to reparse the document each time. It also comes with useful extensions like https://github.com/mike-lischke/antlr4-c3, which generates syntactic and semantic completions directly from the grammar.

I have seen a fair few parser generators over the years, but it has been a long while since I have looked at anything that has been newly developed.

What improvements have been made to make them better? The problem domain seems pretty well defined and even 20 years ago the things that were changing felt like polishing off a few rough edges caused by earlier resource constraints.

I don't want to be dismissive and say "Why make this?" as a implied suggestion that it shouldn't have been made.

Nevertheless, Why make this? I assume there are good reasons for doing this that I am not aware of, what are they?

What is this project's relationship with antlr? I see a different name on the copyright and the github page suggests this is not a part of the antler project, while claiming to be the next generation.

If that's the case, I think it's misleading. It's fine to fork a project, but you don't get to call yourself the next generation of someone else's project.

The Readme has a section for the raison d'être for it compared to the original ANTLR: https://github.com/antlr-ng/antlr-ng?tab=readme-ov-file#futu...

Why -ng ? I thought it had something to do with angular.

I used ANTLR to create a grammar file for MK (Manufacturing Knowledge). I plugged the JavaScript parser and lexer into Ace editor. Good memories.