Re: Design/structure X3 parser more like Qi parser

On 12/20/2016 03:02 AM, Sandro Pirkwieser wrote:
Hi Sandro.
 > 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.

I've not measured the compile time; however, I assume it
would take more time because of the template metaprogramming
required at these places:

   * parse_rhs_main:

https://github.com/boostorg/spirit/blob/master/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L184

     where a new context is created.

   * default parse_rule:

https://github.com/boostorg/spirit/blob/master/include/boost/spirit/home/x3/nonterminal/rule.hpp#L37 


     where the rule_definition is looked up.

However, I realize that's rather circumstantial evidence and
maybe an actual benchmark is needed to show *if* there's a
significant compile-time cost.

 >
 >> 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.
[snip]
 >> 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).

I think this is the problem described here:

http://boost.2283326.n4.nabble.com/x3-devel-why-2-methods-linking-rule-to-RHS-tp4688021.html

which is another reason, besides the assumed compile time
penalty, for using BOOST_SPIRIT_DEFINE.

 > 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<>.

I've updated the code to use an Ops template parameter to
the calc1_gram::gram_deriv:

https://github.com/cppljevans/spirit/blob/ExagonLinkingError/workbench/x3/rule_defns/parse_rule_crtp.cpp#L160

The Ops parameter shows how to change the character use for
the arithmetic operators somewhat like the main_x3's
make_csv_parser's fieldSep argument.

That method is not as "clean" as passing a runtime parameter
thru the argument list, but it's close.

I failed to find documentation for the x3::with; hence, I
couldn't try that.  I even tried grepping the source code;
however, all I found was names beginning with with_ but no
x3::with.  That was with boost_1_61_0.  Do you know where I
could find examples or documentation of x3::with?

HTH,

Larry



------------------------------------------------------------------------------
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