Lexer and parser generators using CTFE

[Andrei Alexandrescu]

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