How future-safe is it to write a parser with Boost Spirit X3?

Question

I'm considering writing what is essentially my first parser since forever (= since the compiler class at Uni which I've forgotten mostly).

Since I use C++, I was thinking of using Boost Spirit. Then I noticed there's the "regular" 2.5.2 and there's something magical subset of the code named Spirit X3.

I' also ve noticed that Boost Spirit X3 was announced/discussed/pre-released already 2 years ago, yet Boost Spirit's official version is 2.5.2. Finally, I read:

Where is boost-spirit 3? Is it abandoned?

So I "know" that it's not an abandoned project - but not a very actively maintained project. How "safe" is it for me to write a parser with Spirit X3? Is it possible it might fail / be dropped / be abandoned, or is it certain to become the main line of Boost Spirit release?

score 2 · Accepted Answer · answered Jul 10 '17 at 15:18

It's already released, so there's little chance of it just vanishing.

I liberally use X3 even in production code: After all, we do have tests for a reason.

That said, I know a number of hairy issues surround the linking of rules spread across separate translation units¹.

Here's a list of things that make me consider not using X3 in the following cases:

where Qi's attribute transformation logic is more enticing (makes for more readable rules). See e.g.
Phoenix integration is desired Boost Spirit X3 cannot compile repeat directive with variable factor
Sharing rules across TUs is desired

Slightly less pressing differences are when:

locals are involved ("X3 becomes a real tedium, (if not completely unbearable) with stateful rules (by which I mean rules with "locals")"). A lot of it can be solved using with<>: Boost Spirit X3 cannot compile repeat directive with variable factor but I'm not convinced it's re-entrant
lazy rule invocation is required²
Lexer is desired (i.e. I wouldn't port a Qi/Lex grammar to X3, except by rewrite)

Note however, there are definite areas where X3 shines:

compilation time
ease of generating dynamic rules/custom directives (see boost::spirit::x3 attribute compatibility rules, intuition or code? or Recursive x3 parser with results passing around)
ease of creating custom parsers (e.g. Spirit-Qi: How can I write a nonterminal parser?)

¹ see the mailing list, and e.g. x3 linker error with separate TU and linking errors while separate parser using boost spirit x3

² In fact, it might be "easy" to create one by creating a custom parser, building on with<> and any_parser<>

So, I +1 you for the detailed answer, but - doesn't your answer imply that it's going to stay the "less-used brother" of the mainline into the future as well? Or are they just working on improving the stiuation with stateful rules, independent lexer etc.? — einpoklum, Jul 10 '17 at 15:30
I merely confirm that it's officially experimental (unstable: the interface may change, there are warts). I have no claim about the future (I do not think it will remain less-used, that will probably depend on widespread adoption of c++14 only). They're working on the linking issues, but I'm not overly optimistic in that respect (TBF: I don't consider external linkage a requirement at all, but that's me). Lexer support is not gonna happen (me using [my crystal ball](https://chat.stackoverflow.com/transcript/10?m=20528855#20528855)) — sehe, Jul 10 '17 at 16:00
Despite the previous comment saying "Lexer support is not gonna happen", Peter Huene implemented his own lexer support in a personal project here: https://github.com/peterhuene/puppetcpp/blob/master/lib/include/puppet/compiler/lexer/lexer.hpp — BenRI, Aug 11 '18 at 22:24

How future-safe is it to write a parser with Boost Spirit X3?

1 Answers1

Linked