Rule Parsers require more explanation

[akrzemi1]

After reading section Rule Parsers, but without being familiar with Boost.Spirit, one doesn't really get the picture why one would want to create such rules, rather than using parsers directly.

I guess that the motivation is to store them as members in classes, but that is more of a guess. I remember that in Boost.Spirit this was a workaround for not being able to use auto type deduction for class members. Is this the case also for Boost.Parser? If so, maybe an example with a parser as a class member would be useful?

There is a a note at the end of the section:

The existence of rules means that will probably never have to write a low-level parser. You can just put existing parsers together into rules instead.

The computer font implies that rules is an identifier defined in the library, but there is no rules defined. Only rule.

I also do not understand what it means. I can also just put the existing parsers together without using a rule:

auto doubles = bp::double_ >> *(',' >> bp::double_);

Also, is it possible to have two rules that reuse the same parser?

Finally, the mechanism for defining rules promotes the usage of elaborated type specifier. This works fine in 98% of the cases, but might cause surprising errors in the remaining 2% as showed in this lightning talk.

[akrzemi1]

Also, the same page mentions that macro BOOST_PARSER_DEFINE_RULE "expands to two overloads of a function called parse_rule()". This is the first time that the reader is exposed to the name parse_rule() and it is not clear how relevant it is to the reader, and that these are two overloads.

Insted, the important information, I think, is that the new rule is also itself a parser.

[tzlaine]

Yes, these things definitely need amplification. I find it particularly difficult to document things that I've internalized so much that I "just know" about them. So, keep these kinds of issues coming; I appreciate them.

[akrzemi1]

Or are they needed when parsers refer to one another recursively?