Hi Akim, Re flex/bison, ANTLR, and racing cars:
I think bison has a number of cool features, in particular nice error handling, support for full LR(1), and glr. They definitely give it an edge over other parser generators. Where it fails: Mundane things like clunky interface with a scanner, too many includes - so too many build dependencies. The latter is partially related to the scanner interface, e.g. if the scanner were integrated, there would be no need to generate parser.h in many cases, i.e. one could manage with a single generated file parser.c[pp]. It would be nice to have some stats about how parser generators (not just bison) are used (maybe you have it). My speculation is that it's mostly *not* about programming languages. Most of my parsers are for simple expressions (every now and then there is some legacy pre-XML format that is mostly regular but has fields containing expressions). In such use-cases, the mundane things prevail and people will increasingly choose e.g. ANTLR for new projects. Ok, maybe they would still choose bison for racing cars (i.e. programming languages). I'm not sure what are the future plans for bison, but I hope it has not quite reached that stage when one declares that it has done its service to the community and it's time to retire and give way to the younger generation... So I'd still consider the possibility of integrating a scanner generator into bison, maybe a severely cut-down version of flex, without any fancies like REJECT, etc. Essentially, it should be possible to build an equivalent of calc++ with only calc++.y and generated calc++.cpp, without any other files. I'd vote for this as the most desirable feature. I realise it's much work, but I believe without this bison will eventually lose to ANTRL. Cheers, Victor.
