Proto for Boost mailing list page: Re: [proto] Thoughts on traversing proto expressions and reusing grammar

Subject: Re: [proto] Thoughts on traversing proto expressions and reusing grammar
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-10-08 03:12:21

On Thursday 07 October 2010 23:06:24 Eric Niebler wrote:
> On 10/4/2010 1:55 PM, Eric Niebler wrote:
> > The idea of being able to specify the transforms separately from the
> > grammar is conceptually very appealing. The grammar is the control
> > flow, the transform the action. Passing in the transforms to a grammar
> > would be like passing a function object to a standard algorithm: a
> > very reasonable thing to do. I don't think we've yet found the right
> > formulation for it, though. Visitors and tag dispatching are too
> > ugly/hard to use.
> > 
> > I have some ideas. Let me think some.
> 
> Really quickly, what I have been thinking of is something like this:
> 
> template<class Transforms>
> struct MyGrammar
> 
>   : proto::or_<
> 
>         proto::when< rule1, typename Transforms::tran1 >
>       , proto::when< rule2, typename Transforms::tran2 >
>       , proto::when< rule3, typename Transforms::tran3 >
> 
> {};

I don't think this is far away from what i proposed.
Consider the following:

template <typename>
struct my_grammar
    : proto::or_<
         rule1
       , rule2
       , rule3
{};

template <typename> my_transform;

// corresponding to the tag of expression of rule1
template <> struct my_transform<tag1>
    : // transform
{};

// corresponding to the tag of expression of rule2
template <> struct my_transform<tag2>
    : // transform
{};

// corresponding to the tag of expression of rule3
template <> struct my_transform<tag3> 
    : // transform
{};

typedef proto::visitor<my_transform, my_grammar> 
algorithm_with_specific_transforms;

In my approach, both the transform and the grammar can be exchanged at will.

What i am trying to say is, both the transforms and the control flow (aka the 
grammar) intrinsically depend on the tag of the expressions, because the tag 
is what makes different proto expressions distinguishable.
This imminent characteristic of a proto expression is what drove Joel Falcou 
(i am just guessing here) and me (I know that for certain) to this tag based 
dispatching of transforms and grammars.

> 
> That is, you parameterize the grammar on the transforms, just the way
> you parameterize a std algorithm by passing it a function object. Each
> grammar (I'm thinking of starting to call Proto grammars+transforms
> "Proto algorithms", because really that's what they are) must document
> the concept that must be satisfied by its Transforms template parameter
> (what nested typedefs must be present).
> 
> This is extremely simple and terse. It gives a simple way to extend
> behaviors (by deriving from an existing Transforms model and hiding some
> typedefs with your own).
> 
> I know this is not general enough to meet the needs of Phoenix, and
> possibly not general enough for NT2, but I just thought I'd share the
> direction of my thinking on this problem.