RE: Enhancement request: enabling Variant in C parsers

[Victor Khomenko]

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.