Oh, in case anyone wants to follow the development of X3, here are the Github links:
https://github.com/djowel/spirit_x3
https://github.com/djowel/spirit_x3.git
git@github.com:djowel/spirit_x3.git
The full attribute mechanism works + basic C++lambda support. I’ve ported one example (calc4.cpp) which parses to an AST. The AST remains the same. Only the way the grammars are written had to change.
For a teaser: here’s GCC times:
SpiritX3: TOTAL : 4.27 secs
Spirit2: TOTAL : 10.00 secs
Even faster at CT than the first Spirit3 attempt. Runtime speed? I expect it to be faster than Spirit-2. The rules have changed (pun intentional). Now, there’s no longer the need for virtual functions and auto is used extensively. I expect code size to be smaller too because the compiler can generate more efficient code.
Here’s the calculator grammar (based on calc3.cpp):
///////////////////////////////////////////////////////////////////////////////
// The calculator grammar
///////////////////////////////////////////////////////////////////////////////
namespace calculator_grammar
{
using x3::uint_;
using x3::char_;
x3::rule<class expression, ast::program> const expression;
x3::rule<class term, ast::program> const term;
x3::rule<class factor, ast::operand> const factor;
auto const expression_def =
term
>> *( (char_('+') >> term)
| (char_('-') >> term)
)
;
auto const term_def =
factor
>> *( (char_('*') >> factor)
| (char_('/') >> factor)
)
;
auto const factor_def =
uint_
| '(' >> expression >> ')'
| (char_('-') >> factor)
| (char_('+') >> factor)
;
auto const calculator = x3::grammar(
expression = expression_def,
term = term_def,
factor = factor_def
);
}
using calculator_grammar::calculator;
Is Spirit X3′s switching to lambdas or autos going to help reduce template error spew?
Yes. But that’s not the only way to tackle the problem. The most useful strategy was by simplifying as much template metaprogramming as possible.
What does
x3::rule const expression;
do? I have not seen that syntax before.
Joel,
I have downloaded Spirit X3 and find one issue with the rule design: they may not work correctly if a rule recursion involves a change in context within the recursion because all rules will use the first context. Imagine for example a recursion that changes somewhere the Skip Parser context component, such a change would get ignored within the next recursive call to the rule.
I have created my own parser based on some of your ideas, but to address this particular issue, I have decided to add some variadic template parameters to the rule to specify which of the context characteristics can affect the rule. This approach has in my opinion two benefits: It solves the issue I mentioned above and it renders explicit the assumptions of possible dependencies on the context, thus leading to cleaner code.
The issue I mentioned gets solved by my approach because when a skip parser is changed, the context that was created with the previous skip parser does not match the correct signature anymore.
I can share my code if you or others are interested.
Michel, I’d need to know more. You can catch us at IRC ##spirit channel. Look for djowel and lets discuss. Ping me there.