|
|
Proto : |
Subject: Re: [proto] Thoughts on traversing proto expressions and reusing grammar
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-10-10 10:45:40
Eric Niebler wrote:
> 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?
Yes, the expression 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.
Ok, sorry. I expressed it wrong. What you described further is exactly what
i meant here
>> 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.
That is correct. But, let's take for example binary expressions, they all
have two children (arity of two), so the only thing you can distinguish one
binary expression from one another is by its tag. Ok, there still is the
domain, but i am assuming only one domain here.
> 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?
Yes that is correct. To avoid further misunderstandings: I am not arguing to
replace proto grammars or transforms, as you said above, you need more than
just the tag to describe valid expressions and transform the expression
trees. I am proposing something something that can coexist and allows the 3
things you listed above.
Proto list run by eric at boostpro.com