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: Joel de Guzman (joel_at_[hidden])
Date: 2010-10-17 21:39:41

On 10/14/2010 4:46 AM, Eric Niebler wrote:
> On 10/13/2010 11:54 AM, Thomas Heller wrote:

>>> I don't get that. There needs to be a phoenex grammar. One, and only
>>> one. I don't see why it's a template, what the tag type is for, or how
>>> one could use a tag to define a "better" phoenix grammar. Because
>>> there's only one. Either an expression is a Phoenix grammar or it isn't,
>>> right?
>>
>> I disagree here.
>> End users might want to extend phoenix (the EDSL itself), by introducing new
>> expressions (right now by introducing a new tag). Now, the user wants to
>> specifiy what valid expressions look like that can be formed with his new
>> expression type. Here i currently can imagine two different scenarios:
>> First, the user just wants to extend our "regular" grammar. This can be
>> achieved by something like this:
>>
>> template<>
>> struct phoenix_grammar<my_new_super_cool_tag>
>>    : // some proto grammar which specifies how valid expressions look like
>>
>> The second scenario i can imagine, that someone wants to build some kind of
>> other language reusing phoenix parts, imagine someone who is so obsessed
>> with functional programming, and doesn't like the current approach and wants
>> a pure functional programming EDSL. Thus he wants to disallow certain
>> expressions. The current visitor design makes that perfectly possible!
>> (I hope this makes things clearer)
>
> No, I'm afraid it doesn't. Extending phoenix by introducing additional
> tags doesn't necessitate parameterizing the *whole* grammar on a tag.
> The old design handled that scenario just fine by using the openly
> extensible proto::switch_. Just one grammar, and users could hook it easily.
>
> And the second scenario also doesn't suggest to me that the grammar
> needs parameterization. It suggests to me that someone who wants a
> radical customization of Phoenix grammar should make their domain a
> sub-domain of Phoenix, reuse the parts they want, and define the grammar
> of their new EDSL.

(still trying to catch up with this thread)

At this point, I am having the same difficulty as (probably) with Eric
in that it seems it's too convoluted and complex. I, for one, don't have
any problems with using switch_ and partial specialization and possibly
sub-classing or template-izing (perhaps using CRTP to let the base
template grammars hook up the most derived, ala static-OOP).

(I'll read some more and see if there are new twists in the thread)

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net