Mixing operator `>>` and `>` considered harmful on the semantics of the combined parser tree

[saki7]

Historically, people believed >> and > are perfectly equivalent in parser's semantics except that > wraps the rhs with expect directive. People believed that ((a > b) >> c) and (a > (b >> c)) are somehow interchangeable and has no observable difference in parser semantics. This is NOT true in current codebase, and was NEVER true in the whole history of Spirit.X3.

During the implementation of boostorg/spirit_x4#50, I found that some parser combinations yield significant difference on how the contents of the exposed container variable is preserved. I then realized that the difference comes from the difference of ((a b) c) and (a (b c)).

((a b) c) means: if (a b) succeeded, parse c.
(a (b c)) means: if a succeeded, parse (b c).

These are definitely not the same and can introduce semantically different parser tree. The alternative parser was one notable example where it produced inconsistent "held" value on above two variants.

At the time of implementing boostorg/spirit_x4#64, I modified the container handling to not expose the observable difference to the library user. In other words, I ignored the semantic difference and made the implementation details more robust so that it crushes the underlying semantic difference.

As a side note, the current operator< has a minor problem where it cannot be the first entity of a combined parser, because there's nothing to chain on the left hand side of the first item (we always needed to use x4::expect[p] in this case).

I think we should reconsider the chained binary expression and instead introduce some unary operator such as ++parser.