Balazs Ree wrote: > By "parser generator" I mean a tool that takes a formal syntax definition > (like BNC), in this case for the .kss syntax, and generates a parser > based on this. This parser then, will be able to parse and compile kss > files and generate whatever output desired.
That's what I thought you meant. And I still think this is nuts. :) > To get a better idea of what a "parser generator" is, please look at the > following example: > > http://www.antlr.org/ > > There are also other approaches to build the parser. There are several > tools and libraries made for this purpose, and one of them can be chosen > to be applied - but you can do without them too, since indeed the > functionality they provide can be just programmed in plain python. The > reason why I am interested to use existing tools and libraries for this > purpose (be it a "parser generator" or not) is that I have bad experience > with "custom made" parsers, including our very own parser for kss. Re-using tools to help you parse the KSS style sheets makes sense to me. Writing a tool (whether based on other tools or not) to code-generate parser in two languages from a single definition sounds very complicated and difficult to maintain. > If we'd keep on using two parsers, it would be an impossible task to keep > then in sync. They would deviate already at the time of creation. This has to be solved by a compatibility test suite, parser generator or not. I don't think more code generation is going to solve this. > And the even bigger > advantage will manifest when there will be no need to maintain and > retrotest two different parser implementations (in two different > languages even). I still think that writing a code generator for two code generators will be pretty hard to maintain. > If the parser generator approach is not used, then I agree it may be more > difficult or impossible to get a python and js parser from the same > source, so then I would not consider replacing our existing js parser, > but in that case the end result would be that kss looses the ability to > work on non-python platforms, since we would eventually drop maintaining > the js lib and keeping it in sync. If there is someone using and willing to maintain an implementation any language, it will exist. If there isn't, it won't. I don't think that's so bad. > I feel that you believe that the kss libraries can go away altogether, In the short term, maybe not. But certainly parts of them would no longer be needed at runtime, which is a good thing. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Kss-devel mailing list Kss-devel@codespeak.net http://codespeak.net/mailman/listinfo/kss-devel
