Re: [boost] [challenge!] find a common domain

Subject: Re: [boost] [challenge!] find a common domain
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2010-05-19 17:47:56

On Wed, 19 May 2010, Eric Niebler wrote:

> On 5/19/2010 2:25 PM, Jeremiah Willcock wrote:
>> On Wed, 19 May 2010, Eric Niebler wrote:
>>> On 5/19/2010 2:08 PM, Marco wrote:
>>>> I am a bit surprised by:
>>>>
>>>> // These should be ambiguous.
>>>>     BOOST_MPL_ASSERT((is_same<deduce_domain3<DD1, DD0, DD0>::type,
>>>> not_a_domain>));
>>>>     BOOST_MPL_ASSERT((is_same<deduce_domain3<DD0, DD1, DD0>::type,
>>>> not_a_domain>));
>>>>     BOOST_MPL_ASSERT((is_same<deduce_domain3<DD0, DD0, DD1>::type,
>>>> not_a_domain>));
>>>>
>>>>
>>>> I was expecting something like:
>>>> BOOST_MPL_ASSERT((is_same<deduce_domain3<DD1, DD0, DD0>::type,
>>>> default_domain));
>>>>
>>>> Am I missing something ?
>>>
>>> This is a tricky case, and to understand why I want that result, you
>>> need to know what proto uses domains for. In proto, you put an
>>> expression in a domain to give it certain domain-specific behaviors.
>>> (E.g. lambda expressions should have an operator() that evaluates the
>>> lambda.) However, there are no domain-specific behaviors to the
>>> default_domain. (E.g. "42" is in the default_domain. Obviously, it has
>>> no domain-specific behavior itself, but "lambda::_1 + 42" should be in
>>> the lambda domain.)
>>>
>>> If you combine two expressions in different domains, and the only
>>> super-domain they have in common is default_domain, then that would
>>> effectively strip all domain-specific behavior from the new expression.
>>> IMO, this would be surprising. Instead, I'd rather make this case
>>> ambiguous -- proto doesn't know what domain-specific behaviors to give
>>> the new expression so it gives up.
>>>
>>> I acknowledge that it is a special case and that this result doesn't
>>> follow naturally from the other rules.
>>
>> How do the rules for default_domain (and domains derived from it) fit
>> into that picture?  Expressions from different domains not derived from
>> default_domain produce not_a_domain in the case of conflicts,
>
> Right.
>
>> while a
>> pair in which one element is derived from default_domain will always
>> choose that element as the domain of the new expression.
>
> Here, you mean "the other element" -- that is, the domain that is not a
> sub-domain of default_domain. The family of domains rooted at
> default_domain is weaker than all others.

OK.  I implemented it the other way around -- choose the 
default_domain-derived domain if the other one isn't derived from that 
base.  The two cases to flip to fix that are the second and third 
specializations of deduce_domain2_cases.

>> In my
>> implementation, if both domains derive from default_domain but are
>> otherwise incompatible, the result will be default_domain,
>
> That's not right for the reason I stated above. And that's the case that
> hung me up for a while.

What do you want there?  not_a_domain?  Is default_domain itself a domain 
that's accessible to users (i.e., they can have an element with 
default_domain as its domain)?  In that case, when do two domains that 
both derive from default_domain conflict?  They have a common ancestor, 
namely default_domain.  Or should default_domain be special in that 
regard, with a rule such as "if the merger of two domains is 
default_domain but one of them isn't default_domain, replace the result 
with not_a_domain"?

>> but normal
>> domains do not derive from default_domain and so end up with the
>> not_a_domain behavior in the case of conflicts.
>
> This part is right.

OK.

-- Jeremiah Willcock