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

Subject: Re: [boost] [guidelines] why template errors suck
From: Smith, Jacob N (jacob.n.smith_at_[hidden])
Date: 2010-09-27 14:04:45

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]] On Behalf Of Eric Niebler
> Sent: Monday, September 27, 2010 10:53 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [guidelines] why template errors suck
> 
> 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

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

-j.