Re: [boost] [guidelines] why template errors suck

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-27 14:13:27

On 9/27/2010 2:04 PM, Smith, Jacob N wrote:
> On Monday, September 27, 2010 10:53 AM, Eric Niebler wrote:
>> On 9/27/2010 1:02 PM, David Abrahams wrote:
>>> On Sep 27, 2010, at 10:11 AM, Eric Niebler wrote:
>>>> On 9/27/2010 12:49 AM, David Abrahams wrote:
>>>>> At Sun, 26 Sep 2010 22:31:54 -0400, Eric Niebler wrote:
>>>>>>>> No. rule::operator= expects SpiritParser to be a strongly-typed
>> tree.
>>>>>>>
>>>>>>> Meaning?  Spell it out and you have your requirements.
>>>>>>
>>>>>> Meaning:
>>>>>>
>>>>>> + If the topmost node has tag-type "plus", there must be exactly
>> one
>>>>>> child node that models SpiritParser
>>>>>> + If the topmost node has tag-type "shift_right", there must be
>> exactly
>>>>>> two child nodes that model SpiritParser,
>>>>>> + If the topmost node has tag-type "subscript", there must be a
>> left
>>>>>> node that models SpiritParser and a right node that models
>> PhoenixLambda,
>>>>>> ...
>>>>>> etc, etc, etc, ad nauseum
>> <snip>
>>>>>> How do I express that as a concept?
>>>>>
>>>>> Summoning up my dim memory of proposed concept notation (so there
>> are
>>>>> guaranteed nits to pick), that might translate into something like:
>>>>>
>>>>> concept SpiritNode<typename Node, typename Tag>
>>>>> {
>>>>> }
>>>>>
>>>>> template <class Node>
>>>>> concept_map SpiritNode<typename Node, plus>
>>>>> {
>>>>>    requires SameType<Node::children,int_<1> >;
>>>>>    typename child_t;
>>>>>    requires SpiritParser<child_t>;
>>>>>    child_t child;
>>>>> }
>>>>>
>>>>> template <class Node>
>>>>> concept_map SpiritNode<typename Node, shift_right>
>>>>> {
>>>>>    requires SameType<Node::children,int_<2> >;
>>>>>    typename child1_t;
>>>>>    requires SpiritParser<child1_t>;
>>>>>    typename child2_t;
>>>>>    requires SpiritParser<child2_t>;
>>>>>
>>>>>    child1_t child1;
>>>>>    child2_t child2;
>>>>> }
>>>>>
>>>>> template <class Node>
>>>>> concept_map SpiritNode<typename Node, subscript>
>>>>> {
>>>>>    requires SameType<Node::children,int_<2> >;
>>>>>    typename child1_t;
>>>>>    requires SpiritParser<child1_t>;
>>>>>    typename child2_t;
>>>>>    requires PhoenixLambda<child2_t>;
>>>>>
>>>>>    child1_t child1;
>>>>>    child2_t child2;
>>>>> }
>>>>>
>>>>> concept RHSOfAssign<typename X>
>>>>> {
>>>>>    typename tag_type; // Every RHSOfAssign has an associated
>> tag_type
>>>>>    requires SpiritNode<X, tag_type>;
>>>>> }
>>>>>
>>>>> This isn't really how concepts were "meant to be used," though.
>>>>
>>>> You haven't shown how the SpiritNode and SpiritParser concepts are
>>>> related.
>>>
>>> Of course not; you didn't say they were related.  I just translated
>> the constraints you wrote down into concepts-land.
>>
>> You were the one who invented the SpiritNode concept, and then didn't
>> tie it into the discussion! I described a recursive description of the
>> SpiritParser concept and you showed one without any recursive property
>> at all. :-P
>>
>>>> There must be some recursive relationship, like "a SpiritParser
>>>> is a SpiritNode<plus> /or/ a SpiritNode<right_shift> /or/ ..."  It
>>>> requires OR constraints
>>>
>>> Do say that, you just use concept_maps to declare that
>> SpiritNode<plus> models SpiritParser, etc.:
>>>
>>>   concept_map SpiritParser<SpiritNode<plus> >
>>>   {
>>>       // ...
>>>   }
>>>
>>>   concept_map SpiritParser<SpiritNode<right_shift> >
>>>   {
>>>       // ...
>>>   }
>>
>> Not according to my reading of the standard. A concept_map is for
>> mapping *types* to concepts, not *concepts* to concepts, as you appear
>> to be doing here.
>>
>> The grammar for a concept_map requires the thing after "concept_map" to
>> be a concept-id, which may include a template-argument-list (as yours
>> does). That consists of template-arguments which are
>> constant-expression, type-id, or id-expression. I looked up each. None
>> appear to allow concept-ids.
>>
>> I can also find no examples in the standard of using concept maps to
>> map
>> one concept to another. Can you?
> 
> I ported parts of the BGL, GIL, MTL, and IETL to ConceptGCC. Then I set up a modeling relationship between the various concepts (in layers) to implement the Shi-Malik algorithm for image segmentation. I wrote up the results:
> 
> http://portal.acm.org/citation.cfm?id=1289971.1289984

I can't access the pdf. Can you put it someplace we can read it?

I'm not sure about MTL or IETL, but I know that BGL and GIL are generic
libraries cut from the same cloth as STL: algorithms over homogeneous
containers. I'm not sure the same techniques apply to heterogeneous
composites like Proto trees.

> Mapping concept-to-concept is part of the core ideas defined by Gregor & Stroustrup.

Then it seems curious that the standard didn't seem to allow it.

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