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