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

Subject: Re: [proto] proto-11 progress report
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2012-06-25 03:39:56

On 06/24/2012 01:10 AM, Eric Niebler wrote:
> I've made some good progress on the C++11 proto rewrite that I'd like to
> share. So far, it's been a less radical shift than I expected.

You didn't try hard enough ;)

> Expressions vs. Grammars
> ========================
> Many new users are confused by the difference between terminal<int> and
> terminal<int>::type. In proto.next, there is no difference. Forget the
> ::type. Things just work.

Neat

> Custom transforms are simpler
> =============================
> Currently, defining a custom transform means defining a struct with a
> nested impl class template of 3 parameters, correctly inheriting and
> following a protocol. In the rewrite, I wanted to simplify things. Here
> for instance, is how the _expr transform is defined:
>
>      struct _expr
>        : transform<_expr>
>      {
>          template<typename E, typename ...Rest>
>          auto operator()(E && e, Rest &&...) const
>          BOOST_PROTO_AUTO_RETURN(
>              static_cast<E &&>(e)
>          )
>      };
>
> A custom transform is simply a struct that inherits from
> proto::transform and that has an operator() that accepts an arbitrary
> number of parameters. (The use of BOOST_PROTO_AUTO_RETURN is not
> necessary. It simply handles the return statement, the return type, and
> the noexcept clause.)

Good

> Data parameter uses a slot mechanism
> ====================================
> In proto today, transforms take 3 parameters: expression, state and
> data. As you can see from above, transforms in proto-11 take an
> arbitrary number of parameters. However, that can make it hard to find
> the piece of data you're looking for. Which position will it be in?
> Instead, by convention most transforms will still only deal with the
> usual 3 parameters. However, the data parameter is like a fusion::map:
> it will have slots that you can access in O(1) by tag.
>
> Here is how a proto algorithm will be invoked:
>
>    int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);
>                                     ^^^^^^^^^^^^^^^^^^^^
> The 3rd parameter associates the value 8 with the data tag. The _data
> transform returns the data associated with that tag. Additionally, you
> can define you own tags and pass along another blob of data, as follows:
>
>    int i = LambdaEval()(_1 + 42, 0, (proto::tag::data = 8, mytag = 42));
>
> The _data transform will still just return 8, but you can use
> _env<mytag_type> to fetch the 42. The third parameter has been
> generalized from an unstructured blob of data to a structured collection
> of environment variables. Slots can even be reused, in which case they
> behave like FILO queues (stacks).

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

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

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

Glad it is picking up steam :D