Re: Design/structure X3 parser more like Qi parser

Hi Larry,

> This doesn't use BOOST_SPIRIT_DEFINE, and I don't think it can because 
> that would generate one or more parse_rule's template functions within 
> the make_csv_parser function.  Is that right?
> If so, then wouldn't that make this method slower to compile than if 
> BOOST_SPIRIT_DEFINE could be used?

yes, to my knowledge using BOOST_SPIRIT_DEFINE inside a function, e.g. make_csv_parser, is not possible.
But I don't know whether this influences compile time.

> In contrast, the following:
> https://github.com/cppljevans/spirit/blob/ExagonLinkingError/workbench/x3/rule_defns/parse_rule_crtp.cpp
> shows a *prototype* of how to emulate the qi method in a revised x3
> *and* use something like BOOST_SPIRIT_DEFINE.
> This parse_rule_crtp prototype modifies the spirit parse_rule by returning a rule_definition instead of using a rule_definition within it's body. 
> This returned rule_definition is then used in the gram_base::rule::parse function. 
> It also defines specializations of parse_rule in the *derived* class and uses CRTP to invoke those specializations in the gram_base::rule::parse function.

> This use of BOOST_SPIRIT_DEFINE avoids the extra compile time needed by make_csv_parser method above;
> hence, Seth, I'm wondering what the advantage of *not* using the BOOST_SPIRIT_DEFINE method for associating a rule with it's rule_definition?

> As the comments at the top indicate, I question (as Seth did in an earlier post) whether there's any advantage to this method.
> Hence, Sandro, could you provide some use-case for this feature?

The main topic (aside the more recent performance analysis) was the question to "better" (at least in my view) encapsulate an X3 parser than with namespaces, i.e. more in the style of a Qi parser. There a larger, more complex parser can be built by incorporating several smaller ones as class members, yet retaining a nice encapsulation. Something that does not seem possible with X3.
An alternative, using parsers defined in functions (as for make_csv_parser), is not always an option though, as such parsers cannot be recursive (rule A is defined via rule B and vice versa).

Your prototype allows using BOOST_SPIRIT_DEFINE inside a struct, hence would definitely come closer to the Qi like encapsulation.
I haven't tried it yet, but is it also possible to use parameters, like the field separator fort the CSV parser? As it can't be given at the time of construction, as for make_csv_parser(), one could probably use x3::with<>.

Best regards,
Sandro

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel