Re: [boost] [contract] syntax redesign

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) \
> 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)Â  
> 

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):

#define CONTRACT_DETAIL_PP_FUNC_TRAITS_ACCESS_TRAIT_(sign) \
    CONTRACT_DETAIL_PP_TRAITS_AUX_NIL /* optional trait */ \
    CONTRACT_DETAIL_PP_TRAITS_AUX_KEYWORD3(sign, \
            BOOST_DETAIL_PP_KEYWORD_IS_PUBLIC_FRONT, public, \
            BOOST_DETAIL_PP_KEYWORD_IS_PROTECTED_FRONT, protected, \
            BOOST_DETAIL_PP_KEYWORD_IS_PRIVATE_FRONT, private)

http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/syn/src/contract/detail/preprocessor/traits/func/access.hpp?revision=1047&view=markup

#define CONTRACT_DETAIL_PP_FUNC_TRAITS_VIRTUAL_TRAIT_(sign) \
    CONTRACT_DETAIL_PP_TRAITS_AUX_NIL /* optional trait */ \
    CONTRACT_DETAIL_PP_TRAITS_AUX_KEYWORD(sign, \
            BOOST_DETAIL_PP_KEYWORD_IS_VIRTUAL_FRONT, virtual)

http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/syn/src/contract/detail/preprocessor/traits/func/virtual.hpp?revision=1047&view=markup

And all the bits are put together here:

http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/syn/src/contract/detail/preprocessor/traits/func.hpp?revision=1047&view=markup

> 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
boost/detail/preprocessor/keyword/:

https://svn.boost.org/svn/boost/sandbox/local/boost/detail/preprocessor/keyword/

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
src/contract/detail/preprocessor/keyword/).

Thanks.
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p4298850.html
Sent from the Boost - Dev mailing list archive at Nabble.com.