[Kss-devel] Summer of Code ideas

[Balazs Ree]

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