On 10/8/2010 12:12 AM, Thomas Heller wrote: > 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
Do you mean expression tag, like proto::tag::plus, or some other more abstract tag? > 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. I don't know what this can possibly mean. Grammars and transforms are not substitutable for each other in *any* context. > 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 is where I disagree. There are many cases where the top-level tag is insufficient to distinguish between two expressions. That's why Proto has grammars. Proto::switch_ dispatches on tags, but I consider switch_ to be primarily an optimization technique (although it does have that nice open-extensibility feature that we're using for Phoenix). > 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. Understood. OK, the problem you're trying to solve is: A) Have an openly extensible grammar. B) Have an equally extensible set of transforms. C) Be able to substitute out a whole other (extensible) set of transforms. Is that correct? -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto