Re: [boost] compile time parser generator

Subject: Re: [boost] compile time parser generator
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-01-07 22:06:17

on Sat Jan 07 2012, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:

> From: Dave Abrahams
>> on Fri Jan 06 2012, "Martin Bidlingmaier" <Martin.Bidlingmaier-AT-gmx.de> wrote:
>
>>> with c++11's constexpr it got possible to parse strings in c++ at
>>> compile time. I've written a parser generator to create an AST for a
>>> given EBNF syntax at compile time, which can be traversed at both run
>>> time and compile time (actually, parsing can take place at run time,
>>> too, but it's probably rather slow). At the moment, the only compiler
>>> I know of that implements enough of c++11 features is gcc (version >=
>>> 4.6). Is refining my implementation worth the effort, has such a
>>> library a chance to make it into boost? 
>
>> It was only a matter of time before someone proposed this.  Of course it
>> has a chance to make it into boost.  I guess the the first question will
>> be, "can you describe some plausible use-cases?"
>
> Regular expressions.

Yeah, sort of like xpressive.

> If there were an interpreted language (perhaps domain specific) with a
> simple grammar then we could inline string constants with code into
> C++ code that gets parsed at compile time to generate executable code.
> So simple things like sed and awk scripts could also be inlined into
> C++ as string literals and translated to executable code at compile
> time instead of runtime if you combine the interpreter library with
> the compile time parsing library.  The benefit over run time
> interpretation of the string is debatable.  It is only a performance
> optimization.  I would say regular expression is the thing that is
> crying out for it.  The real question is what kind of syntax errors
> will it generate when parsing fails?  It would be nice to catch badly
> formed regular expressions at compile time, for e
>  xample, though not so nice if the errors are not so nice.  What this
> allows us to do is extend the language in the form of libraries (in a
> hackish sort of way) which is the desire of modern
>  language theorists from what I've been told by my language theorist
> friends.  I'd say it's almost as exciting as overloading the comma
> operator.

Haha.

Actually, you gain expressivity but lose a lot of power when you do
metaprogramming this way, as compared with TMP.  With TMP you are
working with first-class expressions so you can insert references to
variables and other C++ entities right into your metaprogram.  Also,
different DSLs can be combined (e.g. as in Spirit and Phoenix) to do a
more complicated job.  That's really not so easy when you are working
with strings.

The desire of "modern language theorists" is to enable language
extension without losing interoperability with the rest of the language,
and I think what you can do with constexpr, while very cool, still falls
far short of that.  

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com