Proto for Boost mailing list page: Re: [proto] proto-11 progress report

Subject: Re: [proto] proto-11 progress report
From: Eric Niebler (eric_at_[hidden])
Date: 2012-06-25 12:54:21

On 6/25/2012 12:39 AM, Joel Falcou wrote:
> On 06/24/2012 01:10 AM, Eric Niebler wrote:
<snip>
>>    int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);
>>                                     ^^^^^^^^^^^^^^^^^^^^
>> The 3rd parameter associates the value 8 with the data tag.
<snip>
> 
> How do you set up new tag  ? Is just mytag some
> 
> mytag_type mytag = {};
> 
> ?
> 
> or should mytag_type inherit/be wrapped from some special stuff

Special stuff. Tags are defined as follows:

struct my_tag_type
  : proto::tags::def<my_tag_type>
{
    using proto::tags::def<my_tag_type>::operator=;
};

namespace
{
    constexpr my_tag_type const & my_tag =
        proto::utility::static_const<my_tag_type>::value;
}

The gunk in the unnamed namespace is for strict ODR compliance. A simple
global const would be plenty good for most purposes.

>> As for what is not changing:
>>
>> Grammars, Transforms and Algorithms
>> ===================================
>> It would be wonderful if there were a more natural syntax for describing
>> proto algorithms rather than with structs, function objects, proto::or_,
>> proto::when, and friends. If there is one, I haven't found it yet. On
>> the up side, it means that many current proto-based libraries can be
>> upgraded with little effort. On the down side, the learning curve will
>> still be pretty steep. If anybody has ideas for how to use C++11 to
>> simplify pattern matching and the definition of recursive tree
>> transformation algorithms, I'm all ears.
> 
> There is not so much way to describe something that looks like
> a grammar definition anyway. BNF/EBNF is probably the simplest
> way to do it.

That would be overkill IMO. Proto grammars don't need to worry about
precedence and associativity. Forcing folks to write E?BNF would mean
forcing them to think about stuff they don't need to think about.

> Now on the syntactic clutter front, except wrapping everything in round
> lambda
> or use object/function call in a hidden decltype call, I don't see what we
> can do better :s

More round lambda, sure. Fixing inconsistencies, also. But I tend to
doubt that using grammar-like expressions in a decltype would be a
significant improvement. Folks still can't write transforms in straight,
idiomatic C++, which is what I want.

> Glad it is picking up steam :D

C++11 has made this pretty fun. I'm ready to stop supporting all my
C++03 libraries now. :-)

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