Proto for Boost mailing list page: Re: [proto] looking for an advise

Subject: Re: [proto] looking for an advise
From: Eric Niebler (eric_at_[hidden])
Date: 2010-12-27 14:24:11

On 12/27/2010 5:26 AM, Joel Falcou wrote:
> On 27/12/10 11:02, Maxim Yanchenko wrote:
>> Hi Eric and other gurus,
>>
>> Sorry in advance for a long post.
>>
>> I'm making a mini-language for message processing in our system.
>> It's currently implemented in terms of overloaded functions with
>> enable_if<match<Grammar>>  dispatching, but now I see that
>    
> Dont. this increases copiel time and provide unclear error. Accept
> anykind of expression adn use matches in a
> static_assert with a clear error ID.
> 
>> (a) I'm reimplementing Phoenix which is not on Proto yet in Boost
>> 1.45.0 (that's
>> how I found this mailing list). It would be great to reuse what
>> Phoenix has;
>    
> Isn't it in trunk already Thomas ?

No, it's still in the sandbox. Maxim, you can find Phoenix3 in svn at:

https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3

According to Thomas, the docs are still a work in progress, but the code
is stable.

>> (b) I need to do several things on expressions and I don't know what
>> would be
>> the best way to approach them all.
>>
>> Here is a background.
>> Every message is a multiset of named fields (i.e. is a multimap
>> FieldName->FieldValue).
>> I have a distinct type for each FieldName, so I can do some
>> multiprogramming on
>> sets of FieldNames, like making generating a structure that will hold
>> values of
>> the fields I need, by list of field names (e.g. fusion::map).
>>
>> While processing a message, I can do some checks like if particular
>> field is
>> present, if it's equal or not to some value, if it matches a predicate
>> etc.
>> They are implemented as a set of predicate functions "condition" like
>>
>>    template<  class Msg, class Expr>
>>    typename boost::enable_if<  proto::matches<Expr, proto::equal_to< 
>> proto::_,
>> proto::_>  >, bool>::type
>>    condition( const Msg&  msg, const Expr&  expr )
>>
>> with various condition grammars in enable_if<matches<...>>
>    
> Again, use matches inside the function body.
>    
>> (a) everything runs on enable_if. I expect it to become more concise
>> and clean
>> if I use either transforms or contexts.
>    
> You need none. Put your grammar into a domain with a proper context and
> proto will check operators overload for you.
>    
>> (b) a lot of Phoenix is basically reimplemented from scratch (thanks
>> Eric, with
>> Proto it was very easy to do!). But I don't know how to extend Phoenix
>> so it
>> could work in my expressions with my things like "any_field", "optional",
>> "mandatory" etc.
>    
> Better see what Thomas has up his sleeves in Phoenix.

Right. Maxim, you are totally correct that you are reimplementing much
of Phoenix3, and that the extensibility of Phoenix3 is designed with
precisely these use cases in mind. The only thing missing are docs on
the customization points you'll need to hook.

Thomas, this is a GREAT opportunity to put the extensibility of Phoenix3
to test. Can you jump in here and comment?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com