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)
#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)
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
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.