On Saturday 02 January 2010 05:30:33 Eric Niebler wrote:

There is experimental and undocumented support in Proto for members like else_. See libs/proto/example/virtual_member.cpp for a working example.

Ah, this is what I was looking for. What is the "experimental" and "undocumented" part? -Dave

On 1/3/2010 6:40 AM, David A. Greene wrote:

On Saturday 02 January 2010 11:23:19 David A. Greene wrote:

...

On Saturday 02 January 2010 05:30:33 Eric Niebler wrote:

...

There is experimental and undocumented support in Proto for members like else_. See libs/proto/example/virtual_member.cpp for a working example.

Ah, this is what I was looking for. What is the "experimental" and "undocumented" part?

BOOST_PROTO_EXTENDS_MEMBERS

So following this example, I came up with the attached testcase, modified from the one I posted to the development list.

I know the grammar is not strict enough (it should have a separation between "expressions" and "statements") but that's not important.

With the modified testcase display_expr breaks with an incomprehensible compiler error. I assume I'm missing an operator<< definition somewhere but I don't know where it belongs.

That means the tag types you've defined in the keyword namespace are not Streamable. Define a stream insertion operator on keyword::if_. Using display_expr is documented here: http://www.boost.org/doc/libs/1_41_0/doc/html/proto/users_guide.html#boost_p...

And I'm still getting the same compiler error on the #if 0'd code.

Still on my radar ... -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Saturday 02 January 2010 16:17:03 Eric Niebler wrote:

The attached code compiles. You weren't handling the if_ case correctly. You had specialized ConstructGrammarCases on IfTag, but you weren't using IfTag anywhere, so that specialization wasn't getting picked up. There were a few other small problems, but on the whole, you were pretty close.

If I wanted to keep the IfRule case as a specialization, what should it be specialized on? IfTag was a leftover remnant, so that was a coding error. What I intended to do is this: template<> struct ConstructGrammarCases::case_keyword::if_ : boost::proto::when< IfRule, ConstructBinary<If>(ConstructGrammar(boost::proto::_right(boost::proto::_left)), ConstructGrammar(boost::proto::_right))> {}; But this leads to the compiler error seen earlier. Something like if_ is going to have to use a case_ specialization, so it's necessary to know how this is supposed to work. -Dave

On Sunday 03 January 2010 21:00:31 Eric Niebler wrote:

So you know that the topmost node of an if_ statement has a tag type of boost::proto::tag::subscript. So you should create a case_ specialization on that tag type, as follows:

template<> struct ConstructGrammarCases::case_boost::proto::tag::subscript

So I tried that before and it didn't work. I tried again and it still fails (check attached testcase). I'm using boost 1.40 if it matters. -Dave

On Tuesday 05 January 2010 03:47:39 Eric Niebler wrote:

In your code, you have:

#ifdef NO_SPECIALIZATION template<> struct ConstructStatementGrammarCases::case_boost::proto::tag::subscript

I'm sure if you change your ifdef to ifndef, or just remove the PP gunk, you'll see that it works.

<brownpaperbag> Oh, bother. </brownpaperbag> It works now. And I think I grok proto! I've successfully added more statement-type rules and it works great. A couple of questions: Is there any advantage to doing: // An if_ "operator" template<typename Expr> typename boost::proto::result_of::make_expr< boost::proto::tag::function, Domain, keyword::if_, Expr>::type if_(Expr const &expr) { return boost::proto::make_expr( keyword::if_(), expr); } over: typedef Wrapperkeyword::if_::type> IfTerminal; // An if_ "operator." namespace { const IfTerminal if_ = {{}}; } and letting proto take care of creating the function expression? Perhaps the former has one or two less template instantiations but the latter is certainly easier to maintain. Also, we can get something akin to synthesized attributes with the grammar semantics actions: struct case_ : boost::proto::when< IfRule, ConstructBinary<If>(ConstructExpressionGrammar(boost::proto::_right(boost::proto::_left)), ConstructStatementGrammar(boost::proto::_right))> {}; where Construct*Grammar is a transform grammar that returns some result (so it's a transform too, right?). Is there any way to get something akin to inherited attributes that one can pass down the expression tree? Finally, I think the wrapper metafunction problem I posted about is still an issue, though I seem to be getting by without the dummy template argument to do the ADL trick. -Dave

On 1/7/2010 12:54 PM, David A. Greene wrote:

On Tuesday 05 January 2010 03:47:39 Eric Niebler wrote:

...

In your code, you have:

#ifdef NO_SPECIALIZATION template<> struct ConstructStatementGrammarCases::case_boost::proto::tag::subscript

I'm sure if you change your ifdef to ifndef, or just remove the PP gunk, you'll see that it works.

<brownpaperbag> Oh, bother. </brownpaperbag>

Haha!

It works now. And I think I grok proto!

Welcome to the club. Your propeller hat should arrive in a few days. ;-)

I've successfully added more statement-type rules and it works great.

A couple of questions:

Is there any advantage to doing:

// An if_ "operator" template<typename Expr> typename boost::proto::result_of::make_expr< boost::proto::tag::function, Domain, keyword::if_, Expr>::type if_(Expr const&expr) { return boost::proto::make_expr( keyword::if_(), expr); }

over:

typedef Wrapperkeyword::if_::type> IfTerminal;

// An if_ "operator." namespace { const IfTerminal if_ = {{}}; }

and letting proto take care of creating the function expression? Perhaps the former has one or two less template instantiations but the latter is certainly easier to maintain.

Joel F, already answered this one, and his answer is right. The two formulations are functionally equivalent. The function compiles faster, though.

Also, we can get something akin to synthesized attributes with the grammar semantics actions:

struct case_ : boost::proto::when< IfRule, ConstructBinary<If>(ConstructExpressionGrammar(boost::proto::_right(boost::proto::_left)), ConstructStatementGrammar(boost::proto::_right))> {};

where Construct*Grammar is a transform grammar that returns some result (so it's a transform too, right?).

Yes, all Proto _grammars_ are also _primitive transforms_ and can be used as you are using them above to compose _callable transforms_. (Check the glossary for the meaning of those terms.)

Is there any way to get something akin to inherited attributes that one can pass down the expression tree?

Not exactly sure what you are asking. You mean you want to pass stuff around to all the transforms? All _primitive transforms_ are automatically passed a state and a data parameter. If you don't specify them (you haven't), dummies get filled in for you. You can use one of those to pass around any extra information your transforms need.

Finally, I think the wrapper metafunction problem I posted about is still an issue, though I seem to be getting by without the dummy template argument to do the ADL trick.

Sorry, which issue was that? -- Eric Niebler BoostPro Computing http://www.boostpro.com