On 3/4/12 8:34 AM, Hisayuki Mima wrote:
Certainly, "built AST" option is very interesting. I don't know whether building AST is a common case or not because I'm unfamiliar with syntax analysis. But I'd like to complete ctpg as D version of boost::spirit::qi first. Currently, ctpg can be used probably like boost::spirit::qi. (Both do typed syntax analysis.) There are some points where ctpg is superior to boost::spirit::qi. For example, The source code written by using ctpg is simple because it is like PEG. In addition, I'm planning to improve error messages by making excellent use of #line and __LINE__. I'd like to write the library which is functionally same boost::spirit::qi and written in D style. Hence, I'd like to make implementing "built AST" option i.e. untyped syntax analysis a low priority. What is your idea?
It's your project so you define what's fun to work on. Let me just say that I worked on a lot of parsing-related stuff, and most often projects that start as "this grammar is simple enough, let's just do processing during parsing" ultimately required a rewrite to do generate AST, process it, and then use it for computation.
You can get away without an AST for the simplest grammars (e.g. printf etc.) but in that case you compete with hand-written code. I wouldn't think of parsing a serious grammar with more than a few productions without generating an AST. My intuition is that your work will best excel at those grammars.
Andrei
