Hello! On Sat, Jun 24, 2023 at 3:30 PM Maria Matejka <maria.mate...@nic.cz> wrote: > > Hello! > > On 6/24/23 15:13, Ondrej Zajicek wrote: > > On Thu, Jun 15, 2023 at 03:57:10AM +0200, Alexander Zubkov wrote: > > Also, I think that the current realization in bird relies on the fact > that lexer would not have symbols parsed in advance, i.e. that further > mentions of the keyword should return CF_SYM_KNOWN. But if it is not > the case and the lexer parses forward for some reason (before the > parser creates the symbol for the keyword) it would not return > CF_SYM_KNOWN. I don't know the internals of the lexer and parser much, > maybe it is impossible situation (parser does not backtrack, etc.). > And there is no need to worry here. > > Yes, it is kind of strange, in long-term, it would make more sense to move all > symbol processing from lexer to parser. > > I was moving the symbol processing from parser to lexer several years ago due > to Bison limitations. Flex afaik guarantees that it only parses one token at > a time. The Bison-Flex boundary is a nasty can of worms and I'm afraid that > the best way to get rid of it is to get rid of it altogether. Yet for now, > I'd prefer keeping it as is.
Yes, I see. There are two languages with different structure (config and filter) in the same grammar. And that requires some tradeoffs to be made, at least with its current parsing approach. > > BTW the new method-call code (branch mq-func-types) depends exactly on the > fact that I can manipulate lexer state/context from parser immediately before > parsing the following token. > > Maria > > -- > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
