> > > > Initially not, but now, when I am thinking about it, I don't think so > Bison helps. The syntax of the filter file is nicely linear. Now, the code > of the parser is a little bit larger than minimalistic, but it is due to > nicer error's messages. The raw implementation in Bison raised just "syntax > error" and positions. I did code refactoring, and now the scanning, parsing > and processing are divided into separated routines. Parsing related code > has 90 lines. In this case, I don't think using a parser grammar file can > carry any benefit. grammar is more readable, sure, but we need to include > bison, we need to handle errors, and if we want to raise more helpful > errors than just "syntax error", then the code will be longer. > > I'm not so concerned by code size, but rather parsing of quotations etc and > being able to reason about it's correctness. IMHO that's easier done by > reading a defined grammar than parsing a handwritten parser. > > In this case the complex part is not a parser, but the scanner is complex and writing this in flex is not too easy. I wrote so the grammar file can be more readable, but the usual error from Bison is "syntax error" and position, so it does not win from the user perspective. When a parser is not linear, then a generated parser can help a lot, but using it at this moment is premature.
> Will do a closer review on the patch shortly. > > -- > Daniel Gustafsson https://vmware.com/ > >
