On Thu, 26 Mar 2009 18:10:11 +0900, Martin Aspeli wrote: > 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. :)
Acknowledged :) > >> 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. That's a way to build compilers... any way, I did not intend to win you for this argument, just wanted to show what I meant by "parser generator" because I believed that you misunderstood what I mean by that. If you want to argue that building a compiler with antlr is more complex and takes a bigger effort than building it with library X or say, plain regexp, I can't argue with you before I actually tried and compared all of them. But it is just an example, and the technology chosen for the parser does not affect the rest of the story. -- Balazs Ree _______________________________________________ Kss-devel mailing list Kss-devel@codespeak.net http://codespeak.net/mailman/listinfo/kss-devel
