{"id":914,"date":"2010-01-21T03:00:00","date_gmt":"2010-01-21T11:00:00","guid":{"rendered":"http:\/\/boost-spirit.com\/home\/?p=914"},"modified":"2010-01-23T11:07:58","modified_gmt":"2010-01-23T19:07:58","slug":"what-are-rule-bound-semantic-actions","status":"publish","type":"post","link":"http:\/\/boost-spirit.com\/home\/2010\/01\/21\/what-are-rule-bound-semantic-actions\/","title":{"rendered":"What are Rule Bound Semantic Actions?"},"content":{"rendered":"

In the previous installment<\/a> of the ‘Tip of the Day’ I started to talk about some lesser known features related to semantic actions. Today I will highlight some more details. If a semantic action is attached to a component which is part of an expression assigned to a rule (the rule’s right hand side) it is not only possible to access the attributes of the components it is connected with. In addition it is possible to access rule specific values! Sounds interesting? Read on!<\/p>\n

<\/p>\n

I chose this topic even if I got some comments asking me to avoid writing about things already covered in Spirit’s<\/em> documentation. At the same time, I believe it’s valuable for some of you to repeat the facts from the docs but presented in a more pointed and descriptive way. Additionally, I think the articles as published here lay the ground for more detailed things not yet covered in the docs, but the basics need to be explained properly before we can touch the more advanced stuff. But please leave your comments below telling me what you would like to see highlighted. I am always interested in getting feedback on what works for you and what not.<\/p>\n

Ok, here we go \u2013 let us talk about rule bound semantic actions.<\/p>\n

Any semantic action attached to the right hand side of a rule (or a part of it) is special. We will call those ‘rule bound semantic actions’. Spirit<\/em> provides you with extra placeholder variables (in addition to _1<\/span>, _2<\/span>, etc.) usable to access values related to the enclosing rule (the rule, the expression has been assigned to). For the purpose of this post I assume, that the semantic actions are written using Boost.Phoenix<\/a>. In fact, all placeholders described below are implemented using Phoenix and do not integrate very well with other, similar facilities available in Boost (such as Boost.Bind<\/a> or Boost.Lambda<\/a>). You should avoid mixing Phoenix placeholder with expressions built from those libraries. This is no limitation, as from my experience, using Phoenix is just the simplest way to write semantic actions.<\/p>\n

Let us assume further, that we have a component c<\/span> with an attached semantic action f<\/span>, which is assigned as the right hand side of a rule exposing a synthesized attribute of type Attr<\/span> and providing local variables of types L1<\/span>, L2<\/span>, etc. (I will explain local variables shortly):<\/p>\n

\r\nrule<Iterator, Attr(), locals<L1, L2, ...> > r = c[f];\r\n<\/pre>\n
Here is a list of all predefined placeholders available in the rule bound semantic action F<\/span> (see also the related documentation here<\/a> and here<\/a>):<\/p>\n\n\n\n\n\n\n\n\n\n
Placeholders<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n
_1, _2 ... , _N<\/code><\/td>\nNth attribute of c<\/code><\/td>\n<\/tr>\n
_val<\/code><\/td>\nThe enclosing rule’s synthesized attribute (of type Attr<\/span>)<\/td>\n<\/tr>\n
\n
_a, _b ... , _j<\/code><\/dt>\n<\/td>\n
The enclosing rule’s local variables (_a<\/code> refers to the first of type L1<\/span>, _b<\/span> to the next of type L2<\/span>, etc.)<\/td>\n<\/tr>\n
_r1, _r2 ... , _rN<\/code><\/td>\nThe enclosing rule’s Nth inherited attribute<\/td>\n<\/tr>\n
\n
_pass<\/code><\/dt>\n<\/td>\n
Assign false<\/code> to _pass<\/code> to force a parser or generator failure<\/td>\n<\/tr>\n
\u00a0\u00a0<\/td>\n\u00a0\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
We already talked about _val<\/span>, _1<\/span>, _2<\/span>, etc. last time, and I will not describe inherited attributes today, that is for another day. I would like to concentrate on local variables here.<\/p>\n
Local variables allow to associate arbitrary typed data instances with each rule invocation. These variables are very similar to local variables in a function. They are valid only during the invocation of the rule they are defined in and they automatically go out of scope after the right hand side of the rule has finished executing. Further, each invocation of a rule creates a new set of (default constructed) local variables, even if the same rule is invoked recursively.<\/p>\n
Here is a small Karma<\/em> example generating a list of items prefixed with a sequence number (note: _a<\/span>, eps<\/span>, string<\/span>, lit<\/span>, rule<\/span>, and locals<\/span> are imported from namespace boost::spirit::karma<\/span>).<\/p>\n
\r\nrule<OutIter, locals<int>, std::vector<std::string>()> r =\r\n    eps[_a = 1] << (lit(_a) << eps[++_a] << " " << string) % '\\n';\r\n<\/pre>\n
Let us analyze, what this rule definition does.\u00a0<\/p>\n