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.
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
