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-21 01:50:26

On Thursday 21 October 2010 05:11:49 Eric Niebler wrote:
> On 10/20/2010 7:49 AM, Thomas Heller wrote:
> > I worked a little on trying to simplify that whole grammar with
> > rules that have thing a bit. Forgive me, but i changed the name to
> > Visitor. Why? Simply because i think this is what is done here. We
> > visit a specific node which happened to match our rule.

> Most tree traversal algorithms "visit" each node, but the term "Visitor"
> means something very, very specific: the Gang-of-Four Visitor Design
> Pattern.

We have a tree traversal. *check*
We want to "visit" patterns which represent nodes in our tree. *check*

> It implies an OO hierarchy,

We don't have an OO hierarchy by definition. We have a heterogeneous tree of 
proto expressions. Which is something similar. The Gang-Of-Four didn't new 
about template meta programming.
Suggested line of thought:
 - The proto::expr/proto::basic_expr template is our base class.
 - Subclasses are determined by:
     * tag
     * number of children
     * some specific attributes of children

> a virtual "Dispatch" member that accepts a visitor

By defining a rule in our proto grammar, we "add the virtual dispatch member" 
to a subclass of our hierarchy.

> and a 2nd dispatch to an "Accept" member of the
> visitor object.

this would be: when<Rule, typename Actions::template action<Rule> >

> It is used to "add" members to an OO hierarchy post-hoc
> by putting them in a visitor instead of having to change every type in
> your hierarchy.

Right, with the above attempt of adapting the Gang-Of-Four Pattern, this is 
exactly what we do. It is simply impossible for users to "add" members to 
proto::expr/proto::basic_expr.
 
> If you don't have something like that, then don't call it Visitor. If
> you do, then we need to reformulate this design to make that pattern
> more explicit. Otherwise, it will cause no end of confusion.

What about the above attempt?
 
> Historical note: I originally called the "data" parameter of Proto
> transforms "visitors". During the review, there was such a hue and cry
> (for good reason) that I had to change it. True story.

Wow! FWIW the name data is far better ;)

> > Here it goes:
> >     namespace detail
> >     {
> >     
> >         template <
> >         
> >             typename Grammar, typename Visitor, typename IsRule = void>
> >         
> >         struct algorithm_case
> >         
> >             : Grammar
> >         
> >         {};
> 
> Why inherit from Grammar here instead of:
>   : proto::when<
> 
>         Grammar
>       , typename Visitor::template visit<Grammar>
> 
> 
> ?

Because I wanted to have an "escape" point. There might be some valid 
usecase, that does not want to dispatch to the Visitor/Actions. This is btw 
the reason i didn't reuse or_, but introduced the rules template. To 
distinguish between: 1) "regular" proto grammars --> no dispatch 2) the 
rules, which do the dispatch.

<snip>
> It took a while, but I see what you're up to. You've pushed complexity
> into the generic "algorithm" class. (Not the greatest name, but I can't
> do better at the moment.) The benefit here is the cleaner separation
> between rules and actions, and the nicer syntax for specifying the rules
> associated with a tag. E.g.:
> 
>   rules<A,B,C>
> 
> where A, B, and C are simple Proto rules without semantic actions,
> instead of:
> 
>   proto::or_<
>       rules_with_actions<A, Actions>
>     , rules_with_actions<B, Actions>
>     , rules_with_actions<C, Actions>
> 
> 
> ... which conflates grammar with actions in an unpleasant way. That's a
> significant improvement. I ported my mini-Phoenix to use this, and I
> like it. (See attached.)

Exactly!

> Now the outstanding question is: does this control flow really mirror
> the Visitor design pattern, and if so can we jigger this to more closely
> match that pattern? If so, we could make this easier to use and
> understand.

See above.