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

Subject: Re: [boost] [challenge!] find a common domain
From: Eric Niebler (eric_at_[hidden])
Date: 2010-05-19 18:02:26

On 5/19/2010 2:47 PM, Jeremiah Willcock wrote:
> On Wed, 19 May 2010, Eric Niebler wrote:
>> On 5/19/2010 2:25 PM, Jeremiah Willcock wrote:
>>>
>>> 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.

OK.

>>> 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?  

Yes.

> Is default_domain itself a
> domain that's accessible to users (i.e., they can have an element with
> default_domain as its domain)?  

Yes.

> 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"?

Close. Yes, default_domain is special. If the merger of two domains is
default_domain and /neither of them/ is default_domain, the result is
not_a_domain. Otherwise, the one that's not default_domain dominates.
So, if lambda_domain is a sub-domain of default_domain, it is stronger
than default_domain and should dominate. I.e., "_1 + 42" should be a
lambda expression.

default_domain should *never* be the answer when any domain is not
default_domain.

Gotta pass all the test cases I sent! :-)

>>> 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.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com