Re: Design/structure X3 parser more like Qi parser

On 12/18/2016 08:50 AM, Larry Evans wrote:
> On 12/13/2016 11:56 AM, Seth wrote:
> [snip]
>> The resultant X3 neatly expresses why I don't think modularity of X3 is
>> any problem. It employs only one or two tricks, which **exploit** the
>> fact that X3 is actually /just c++ code/ and behaves as such:
>>
>>     namespace csv {
>>         template <typename Sep>
>>         auto make_csv_parser(Sep fieldSep) {
>>             using namespace boost::spirit::x3;
>>
>>             using R = rule<struct _, CsvString>;
>>
>>             auto unescaped = R{"raw"}    = *(~char_("\"\r\n") - fieldSep);
>>             auto escaped   = R{"quoted"} = *(~char_('"') | '"' >>
>>     char_('"'));
>>             auto lineBreak = eol;
>>
>>             auto field = R{"field"} =
>>                 (*lit(' ') >> ('"' > escaped > '"') >> *lit(' '))
>>                 | unescaped; // the order is important because unescaped
>>     can consume zero characters
>>
>>             auto record = rule<struct _, CsvRecordInformation>{ "record" } =
>>                 field % fieldSep;
>>
>>             auto file   = rule<struct _, CsvFileInformation>{ "file" } =
>>                 ((!eoi > record) % lineBreak) > -lineBreak > eoi;
>>
>>             return file;
>>         };
>>     }
>>
> [snip]
> 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?
>
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?

-regards,
Larry





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot