{"id":1334,"date":"2011-02-12T16:27:43","date_gmt":"2011-02-13T00:27:43","guid":{"rendered":"http:\/\/boost-spirit.com\/home\/"},"modified":"2011-05-27T12:13:49","modified_gmt":"2011-05-27T19:13:49","slug":"attribute-propagation-and-attribute-compatibility","status":"publish","type":"page","link":"http:\/\/boost-spirit.com\/home\/articles\/attribute_handling\/attribute-propagation-and-attribute-compatibility\/","title":{"rendered":"Attribute Propagation and Attribute Compatibility"},"content":{"rendered":"

Narinder Claire asked a seemingly innocent question on the Spirit<\/em> mailing list the other day. After starting to write an answer I realized that this question is not innocent at all as it touches the very fabric of Spirit<\/em>: the rules of attribute handling. Many people have a hard time to properly understand what<\/strong> is going on in the nether regions of Spirit<\/em>. More importantly, they have a hard time to understand why<\/strong> is Spirit<\/em> implemented the way it is.\"\"\"\"<\/p>\n

The question was (I’m paraphrasing to fit it into this article): the following code compiles and runs fine:<\/p>\n

\r\nstd::map<std::string, std::string> the_dictionary;\r\nvoid insert(std::pair<std::string, std::string>& p)\r\n{\r\n    the_dictionary[p.first] = p.second;\r\n}\r\n\r\nnamespace qi = boost::spirit::qi;\r\n\r\ntypedef std::string::iterator iterator;\r\nqi::rule<iterator, std::string()> identifier = qi::alpha >> *qi::alnum;\r\nqi::rule<iterator, std::pair<std::string, std::string>()> assignment;\r\nassignment = identifier >> '=' >> identifier >> ';';\r\n\r\nstd::string input("a=b");\r\nqi::parse(input.begin(), input.end(), assignment[&insert]);\r\n<\/pre>\n
It parses the input ‘a=b’ and calls the function insert() after it  matched the input, passing along a pair of strings “a” and “b”.<\/p>\n
It stops compiling if the semantic action is moved into the  assignment rule:<\/p>\n
\r\nassignment = (identifier >> '=' >> identifier >> ';')[&insert];\r\nqi::parse(input.begin(), input.end(), assignment);\r\n<\/pre>\n
On the other hand, it still compiles and runs if the code is written  as:<\/p>\n
\r\nassignment = (identifier >> '=' >> identifier >> ';');\r\nstd::pair<std::string, std::string> pp;\r\nqi::parse(input.begin(), input.end(), assignment, pp);\r\n<\/pre>\n
What (the hell) is going on? Any help with an explanation would be  appreciated!<\/p>\n
The Attribute Rules<\/h5>\n
Attribute handling in Spirit is governed by two seemingly  contradictory set of rules: attribute propagation<\/em> rules and  attribute compatibility<\/em> rules.<\/p>\n
The attribute propagation<\/em> rules are well formalized and are  described in the documentation for each of the components. They are  applied from the ‘bottom up’, describing how the exposed attributes of  the components compose to form the overall attribute of a Spirit<\/em> expression. For instance, for sequences we find the general rule to be  (see the docs here<\/a>):<\/p>\n
a: A, b: B –> (a >> b): tuple<A, B><\/p><\/blockquote>\n
which reads as:<\/p>\n
Given the parser component a exposes an attribute of type  A and the parser component b exposes an attribute of type B, then the  sequence of parser components a >> b will expose an attribute of  type tuple<A, B>.<\/p><\/blockquote>\n
In terms of attribute propagation<\/em>, tuple stands for  fusion::vector.<\/p>\n
At the same time, the use of ‘tuple’ above already hints at the  attribute compatibility<\/em> rules. It means, that a sequence will be  able to fill any attribute as long as it is a Fusion sequence of any  type (for instance std::pair) holding two elements of type A and B.<\/p>\n
The attribute compatibility<\/em> rules are applied from the ‘top  downwards’. They prescribe whether a user supplied attribute can be  directly used by the component it is passed to. Spirit<\/em> requires a  given attribute type to conform to a set of concepts in order for this  type to be compatible with a component. These concepts are specific to  every parser or generator component. Unfortunately the current  documentation does not contain a full and explicit description of those  conceptual requirements, which is something we definitely need to  improve on in the future.<\/p>\n
Spirit<\/em> enforces these concepts (i.e. the compatibility rules)  by wrapping all attribute handling into special templates, called  customization points. All default implementations of the customization  points (CPs) generally expose a functionality, which is aligned with  what a user would intuitively expect. The tricky part is that you can  provide specializations for all CPs, therefore bending the rules for  your types. However, here are the three main rules of attribute  compatibility in Spirit<\/em>:<\/p>\n