----- Original Message -----
From: Lorenzo Caminiti <lorcaminiti@gmail.com> To: boost@lists.boost.org Cc: Sent: Sunday, January 15, 2012 4:48 AM Subject: Re: [boost] [contract] syntax redesign
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
On Sat, Jan 14, 2012 at 9:58 PM, paul Fultz <pfultz2@yahoo.com> wrote: 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) \ PP_PARSER_OPT(const) PP_PARSER_OPT(volatile) PP_PARSER_VAR //function = (public | private | protected) [virtual] type var (tuple) #define FUNCTION_PARSER(x) \ PP_PARSER_ALT(public, private, protected) PP_PARSER_OPT(virtual) \ PP_PARSER(TYPE_PARSER) PP_PARSER_VAR (PP_PARSER_TUPLE) 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) Also, on what branch can I find the pp keyword facility? I didn't see it on the trunk.