Anyone interested in a Spirit for D?

[Bill Baxter]

Walter Bright wrote:
> Along the lines of Don's regexp template metaprograms, is anyone 
> interested in a Spirit-like parser generator capability in D?
> 
> http://spirit.sourceforge.net/

Now that would be useful I think.

Take this example from the Spirit intro of code to make a parser for a 
list of real numbers:
    r = real_p >> *(ch_p(',') >> real_p);

In EBNF that's just:
    real_number ("," real_number)*

In C++ you have to get creative with the operator overloading there 
(prefix '*' used to denote the regexp Kleene star, '>>' used to separate 
tokens)

But given Don's experiments with compile-time text parsing in D, it's 
conceivable that in D the above parser could just be created with:

    r = make_parser("real_number (',' real_number)*");

I.e. use the EBNF version directly in a string literal that gets parsed 
at compile time.
That would be pretty cool.

Though, you know, even thinking about Boost::Spirit, I have to wonder if 
it really is necessary.  From the intro it says that it's primary use is 
"extremely small micro-parsers", not a full blown language processor. 
But if that's the target then the runtime overhead of translating the 
EBNF description to a parser would be pretty trivial.  So I guess the 
real benefit of a compile-time parser-generator is that your grammar can 
be _verified_ at compile-time.

I wonder if it would be any easier to make a compile-time grammar 
verifier than a full blown parser generator?   Then just do the 
parser-generating at runtime.


---
heh heh, this is fun.  From one of the code examples:

   typedef
    alternative<alternative<space_parser, sequence<sequence<
    strlit<const char*>, kleene_star<difference<anychar_parser,
    chlit<char> > > >, chlit<char> > >, sequence<sequence<
    strlit<const char*>, kleene_star<difference<anychar_parser,
    strlit<const char*> > > >, strlit<const char*> > >
    skip_t;

    skip_t skip;

That monster type signature was determined by deliberately forcing a 
compiler error and then copy-pasting the type from the resulting error 
message.  Too funny.  (Note that this as given not as the main way to 
use the library but as a way to eliminate some of the code bloat all the 
templates lead to -- another reason to not try to generate the parser at 
compile-time, but just verify it.)

At any rate the Spirit documentation seems to be rife with juicy 
comments of the form "yes it looks funky, but we're stuck with C++ 
here".  So it's a good place to get ideas for how to make things better.

--bb