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:25:48

On Wed, 19 May 2010, Eric Niebler wrote:

> (Please don't top-post.)
>
> On 5/19/2010 2:08 PM, Marco wrote:
>> On Wed, 19 May 2010 08:02:56 +0200, Eric Niebler <eric_at_[hidden]> wrote:
> <snip>
>>>
>>> Your job: implement the deduce_domain3 template that finds the common
>>> domain of 3 domains. You're allowed to use decltype, but you get bonus
>>> points for a solution that doesn't. Bonus also for instantiating fewest
>>> templates. The challenge is for the ternary case, but your solution
>>> should scale to N domains. If your solution is better than mine, I'll
>>> use it in Proto and credit you!
>>>
>>> Good luck.
>>>
>>> P.S. I haven't checked my solution in yet, so you can't look in trunk
>>> and cheat. ;-)
>>
>>
>> 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, while a pair 
in which one element is derived from default_domain will always choose 
that element as the domain of the new expression.  In my implementation, 
if both domains derive from default_domain but are otherwise incompatible, 
the result will be default_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.

-- Jeremiah Willcock