Proto for Boost mailing list page: Re: [proto] grammars, domains and subdomains

Subject: Re: [proto] grammars, domains and subdomains
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-12-08 16:44:50

Eric Niebler wrote:

> On 12/8/2010 5:30 AM, Thomas Heller wrote:
>> Eric Niebler wrote:
>>> On 12/7/2010 2:37 PM, Thomas Heller wrote:
>>>> So, How to handle that correctly?
>>>
>>> Yup, that's a problem. I don't have an answer for you at the moment,
>>> sorry.
>> 
>> I think i solved the problem. The testcase for this solution is attached.
>> Let me restate what I wanted to accomplish:
> <snip>
> 
> Thomas,
> 
> A million thanks for following through. The holidays and my day job are
> taking their toll, and I just don't have the time to dig into this right
> now. It's on my radar, though. I'm glad you have a work-around, but it
> really shouldn't require such Herculean efforts to do this. There are 2
> bugs in Proto:
> 
> 1) Proto operator overloads are too fragile in the presence of
> subdomains. Your line (5) should just work. It seems like a problem that
> Proto is conflating grammars with subdomain relationships the way it is,
> but I really need to sit down and think it through.
> 
> One possible solution is an implicit modification of the grammar used to
> check expressions when the children are in different domains. For
> instance, in the expression "A+B", the grammar used to check the
> expression currently is: common_domain<A, B>::type::proto_grammar.
> Instead, it should be:
> 
>    or_<
>        typename common_domain<A, B>::type::proto_grammar
>      , if_<
>            is_subdomain_of<
>                typename common_domain<A, B>::type
>              , domain_of< _ >
>            >()
>        >
>    >
> 
> That is, any expression in a subdomain of the common domain is by
> definition a valid expression in the common domain. is_subdomain_of
> doesn't exist yet, but it's trivial to implement. However ...
> 
> 2) Using domain_of<_> in proto::if_ doesn't work because grammar
> checking is currently done after stripping expressions of all their
> domain-specific wrappers. That loses information about what domain an
> expression is in. Fixing this requires some intensive surgery on how
> Proto does pattern matching, but I foresee no inherent obstacles.
> 
> It'd be a big help if you could file these two bugs.

I will try to present a patch. I urgently need this feature to be 
become officially supported to use it for phoenix3 (a scope opened by let or 
lambda should be it's own sub domains in order to allow local variables, 
theses shall not be allowed in a "regular" expression, and they should be 
combinable with other expressions).
Looking at the bug tracker i find two bugs, which are directly related to 
this:
https://svn.boost.org/trac/boost/ticket/4675
and
https://svn.boost.org/trac/boost/ticket/4668