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 13:53:22

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?

>> which, as Sebastian has pointed out, were yanked
>> from the concepts proposal.
> 
> With good reason.

Algorithmic complexity, IIRC.

>> rule::operator= is an algorithm. The structure of the type on which it's
>> parametrized and the grammar to which that type must conform together
>> determine what the overall algorithm requirements are. It by necessity
>> cannot be expressed without OR constraints.
> 
> I don't understand how you can come to that conclusion with such certainty, while at the same time declaring that you don't understand concepts.

Oh, my shoddy reasoning went something like: "it seems like I would need
an OR constraint." Heh.

>> What I seem to have is a
>> situation where an algorithm has type requirements that cannot be
>> expressed with concepts, so concepts cannot help me validate my type
>> parameter.
> 
> I don't see it (yet), sorry.  Am I missing something?

If I do indeed need an OR constraint or something like it, and OR
constraints were pulled for good reason, then it seems like what I'm
trying to do is D.O.A.

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