On Fri, 05 Dec 2025 10:42:13 +0100 Basile Starynkevitch <[email protected]> wrote:
> Consider also other parsing techniques: hand-written recursive > descent parsers, or using parsers generated by > https://www.antlr3.org/ or by https://carburetta.com/ If I may say so, I'm not sure "don't use Bison" is on-topic advice for the [email protected] mailing list. IMO it's not good advice, either. The OP found a solution with Hans's help. Chalk one up for free software. To write a recursive descent parser is to abandon all the advantages of parser generators. Inconsistencies in the grammar are not reported by the compiler and thus have to be ferreted out by testing. That's akin to using Python instead of C to avoid compilation errors. I've been using Bison for a solid 5 years and have, in GCC COBOL, what might be the biggest grammar ever devised with it. Error messages are an abiding challenge and I've taken my lumps, with more to come. I think in the last year I've spent more time diagnosing bad COBOL than compiling new good COBOL. To date, %define parse.error verbose has sufficed. Doing it by hand is no panacea. The compiler is written in C++ and yours truly has, on occasion, quite rarely you understand, made a C++ mistake. Tragic, I know. Those diagnostics, though, even from the carefully manicured bespoke recursive-descent C++ parser can be read-between-the-lines humdingers. If you don't believe me, ask Bjarne Stroustrup. One wonders at the progress we haven't made. Almost 6 decades ago Algol68 was defined with a 2-level grammar, one for syntax and another for semantics. Much of what we check by hand as "semantic" could be reduced to rules and checked automatically. To date though Algol68 is afaik the only language so defined. Sadly the parser technology was specific to Algol68 and was never adapted to any general-purpose tool. Yacc-like tools remain the state of the art, even as CRTs and 9-track tape gave way to LCD and solid-state storage. --jkl
