On Thu, 15 Jul 2010, Rainer Gerhards wrote: > While I think we alread settle fort he other alternative, there is one point > I'D like to take (as it may be important for future discussions): > >>> One thing though, that is on my feature list is that I would like to >> use a >>> more standard parser, that means one that can becreated with lex and >> Bison. >>> While the hand-crafted parser is fine, it always is more work to >> extend and >>> enhance it. As the parser is no critical component, I'd prefer to use >> the >>> simpler approach. However, I need to check if I can find a suitable >> grammar >>> for this proposal. This also works on the assumption. >> >> I don't see this as a problem. It's work to define a parser, but I >> don't >> think that the current grammer is significantly harder to put into a >> lex/bison parser than any other (the exception being the implicit >> scoping >> rules) > > A problem from the grammer PoV is that a traditional action line has no > structure at all. It is anything from the first non-whitespace after the > filter to the end of line. So here we need LF as a delimiter, while in all > other cases, NL should be consider as whitespace and be discarded.
interesting, I'm not sure that anyone else realized that a config option could be split over multiple lines. I'd lay good odds that you could say that NL/LF is the end of a configuration option in an upgrade without anyone noticing the change. > You really > can't specify this with a decent contextfree grammar, but Flex's substates > most probably provide sufficient power to cover these "two languages in one" > approach. > > But as I said ... this seem no longer be relevant to the current discussion, > as we will probably stick with the current config system and its parser. In the long run it's probably a useful thing to switch from the current parser to a lex/bison based parser. it makes it easier to be sure that you are sticking with the defined config language, and should make it easier to add new options, but it's not a requrement. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
