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

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-09-27 13:02:25

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:
>>> On 9/26/2010 9:44 PM, David Abrahams wrote:
>>>> On Sep 26, 2010, at 8:55 AM, Eric Niebler wrote:
>>>>> On 9/25/2010 1:24 PM, David Abrahams wrote:
>>>>>> On Sep 24, 2010, at 11:51 PM, Eric Niebler wrote:
>>>>>>> On 9/24/2010 9:37 PM, David Abrahams wrote:
>>>>>>> 
>>>>>>> Haha! No, not at all. Let's rephrase the problem a bit. If we still had
>>>>>>> C++0x concepts, what would the concept SpiritParser look like, such that
>>>>>>> we could define spirit::qi::rule::operator= such that it required its
>>>>>>> RHS to satisfy the SpiritParser concept?
>>>>>> 
>>>>>> That's easy to answer; just look at the operations that
>>>>>> operator= et. al expect of such a type. Wouldn't SpiritParser
>>>>>> just be some simple refinement of Callable?
>>>>> 
>>>>> 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
>> 
>> No offense, but did you really answer the question I asked?  Does
>> operator= actually use those requirements?  
> 
> It does. operator= doesn't know how to process the tree (that is, what
> the requirements are) until it looks at the top-most node type and
> dispatches to the correct helper functions. Those functions have their
> own requirements determined solely by the substructure of the trees they
> operate on.
> 
> For instance, take semantic actions, denoted by the subscript tag. If a
> subscript node appears anywhere in the tree, the right child of that
> node must satisfy the concept PolymorphicFunctionObject. rule::operator=
> will fail to compile if it does not; it has assumed that requirement as
> a result of the recursive function calls made within the body of
> operator=. I'd like to be able to check for that condition up front. I
> still don't know how using concepts.
> 
>> On the face of it, it just
>> seems a lot more likely that it simply requires its RHS to also be a
>> SpiritParser.
> 
> Where a SpiritParser is ...?
> 
>>> 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.

> 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> >
  {
      // ...
  }

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

With good reason.

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

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

--
Dave Abrahams
BoostPro Computing
http://boostpro.com