▲ | Philpax 3 days 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. | ||
▲ | vbezhenar 3 days ago | parent | next [-] | |
I've used antlr to generate parser for small language used in one project. It's like 100 declarative lines of code. Writing parser by hand would be a much more complicated task. I didn't really care about diagnostics. It has some, that's enough. And of course it's easier to maintain declarative grammar description. My guess is, that it's often used for those kinds of simple grammars without high requirements to impementation. When you need to get things done. Like regex. You might write code to parse a string in a more efficient way, but with regex it's almost always easier. So ANTLR is like regex engine for more complicated inputs. | ||
▲ | joz1-k 3 days ago | parent | prev | next [-] | |
Most production parsers use their own handwritten recursive descent parsers, not only because of better diagnostics (error handling, language server hinting, etc.), but also for other reasons. One such major reason is that parser generators represent a very unstable dependency. They frequently change their APIs in newer versions, and some are becoming obsolete while new ones are constantly appearing. You don't want to risk the longevity of your parser by basing it on such unstable foundations. Flex/Bison is perhaps the only exception, as it hasn't changed much over time. | ||
▲ | ashwindharne 2 days ago | parent | prev | next [-] | |
I used ANTLR recently to prototype a spreadsheet formula language -- backend was JVM so it was reasonably easy and batteries-included. | ||
▲ | another_twist 3 days ago | parent | prev [-] | |
Quite right. But antlr is better for query parsing. They also have error listeners so error handling can be added. |