Boost logo

Boost :

Subject: Re: [boost] [contract] syntax redesign
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-01-16 03:56:42

paul Fultz wrote
> ----- Original Message -----
>> From: Lorenzo Caminiti <lorcaminiti@>
>> To: boost_at_.boost
>> Cc:
>> Sent: Sunday, January 15, 2012 4:48 AM
>> Subject: Re: [boost] [contract] syntax redesign
>> On Sat, Jan 14, 2012 at 9:58 PM, paul Fultz <pfultz2@> wrote:
>>> It is very impressive. I wonder if a library could be built for writing
>> DSLs using the preprocessor. Much like Boost.Proto lets you write DSLs
>> using C++
>> operators, another library could be used to build grammars and define
>> transformations based on preprocessor tokens.
>> Indeed, my library uses the pp to defined a DSEL for function
>> declarations with contracts, concepts, named parameters, and some
>> C++11 declaration extensions (override, final, etc). Some
>> generalization of the tools used by my library should be possible
>> maybe along the lines of Proto (but I have not looked at implementing
>> such generalization).
>> For now the library implementation performs the following /distinct/
>> steps:
>> 1) Parse the class and function declarations into their traits
>> (preprocessor-meta-traits) using the pp (pp metaprogramming).
>> 2) Expand the macros based on the parsed function pp-meta-traits
>> generating code for contract, concept, named parameter, etc using the
>> both the pp and the compiler (pp and template metaprogramming, plus
>> C++ programming).
>> These steps are distinct so you can replace step 2 to generate some
>> feature other than contracts, concepts, or named parameters. But step
>> 1) always parses the syntax of the DSEL for declarations with
>> contracts, concepts, and named parameters. So step 1) should be broken
>> down into subtools (maybe like a Preprocessor/Proto)...
> I'm thinking of library that let's you define a grammar for the parsing
> stage, which later on can be used to generate the pp-meta-traits. Perhaps,
> a grammar to parse a function could be defined as this:
> //type = [const][volatile] var
> #define TYPE_PARSER(x) \
> //function = (public | private | protected) [virtual] type var (tuple)
> #define FUNCTION_PARSER(x) \
> PP_PARSER_ALT(public, private, protected) PP_PARSER_OPT(virtual) \
> And then PP_PARSER_VAR could represent a keyword or something with
> parenthesis around it(var = keyword | (...)). The parser macro would then
> transform the grammar into some form of pp data structures.  I wonder how
> much of an EBNF grammar could be implemented, or what the syntax would
> look like exactly. Furthermore, instead of building a parser, one could
> just build some transformations, and transform their own DSL into C++ code
> instead going through some intermediate pp data structures. Ultimately,
> the parsers would be considered transformations also(much like grammars
> are considered transformers in Boost.Proto, I believe) 

Yes, it makes sense. Right now step 1) does something _somewhat_ similar but
it would need to be redesigned to be exposed the macros as a public API (as
you suggest and possibly along the lines of Proto):

    CONTRACT_DETAIL_PP_TRAITS_AUX_NIL /* optional trait */ \

    CONTRACT_DETAIL_PP_TRAITS_AUX_NIL /* optional trait */ \

And all the bits are put together here:

> Also, on what branch can I find the pp keyword facility? I didn't see it
> on the trunk.

It's moving :) Currently, it's in Boost.Local under

But during Local review it was decided to only put in Local the 3-4
pp-keywords that Local needs (const, void, inline, bind, etc) so finally
I'll move the pp-keywords back into Boost.Contract (under


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at