Re: Problems with alternative in X3
Lee Clagett <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <20160401010211.58f72cef@laptop-m1330> |
On Sat, 26 Mar 2016 08:26:06 +0800 Joel de Guzman <[email protected]> wrote: > On 24/03/2016 11:19 PM, Lee Clagett wrote: > > On Wed, 23 Mar 2016 15:05:52 +0000 > > Mikael Asplund <[email protected]> wrote: > >> Hi! > >> > >> I have an issue with alternatives that I don't understand why it's > >> happening. I've simplified it even down to just x3::attr():s and I > >> still get the problem. > >> > >> Example here (code also supplied in attachment): > >> > >> http://coliru.stacked-crooked.com/a/bdf4718cdeb2db4d > >> > >> Why does the commented out version on line 57 work, and the active > >> one on line 58-59 not work? It's an alternative of two exactly > >> equal sequences, shouldn't that result in them joining to the > >> attribute type as the single sequence? > >> > >> Regards, > >> Mikael > >> > > > > SpiritX3 does not collapse when alternative branches are identical. > > Instead, X3 requires the attribute after the expect parser to be a > > variant type [0]; only `variant<Foo>` is permitted as an attribute. > > SpiritV2 would remove the variant type from the expected type if it > > held only a single type element, allowing `Foo`, `optional<Foo>`, > > and `variant<Foo>` in this situation. Joel, which is the preferred > > behavior? I can work on a patch + tests if the SpiritV2 approach > > should be taken. > > Is this related to this ticket: > > https://svn.boost.org/trac/boost/ticket/12094 > That ticket is closely related. I agree with your statement in the ticket that the `parse_into_container_impl` specialization for the `alternative` parser was probably a mistake. I found the commit [0] that added this specialization, and found that it was added for cases similar to this: std::string s; BOOST_TEST( (test_attr("ab", char_ >> char_ >> ((char_ % ',') | eps), s )) ); I think the problem was actually the difference in exposed attributes between x3 and Qi: a: A, b: A --> (a | b): A // Qi a: A, b: A --> (a | b): variant<A> // x3 So the exposed attribute above would be: sequence<char, char, container<char>> // Qi sequence<char, char, variant<container<char>>> // x3 I tested a change to `attribute_of<alternative<...>>` to match the behavior of Qi, and removed the `parse_into_impl` specializations for `expect` and `alternative`. This forces the sequence parser to pass the container to the alternative parser when both alternations collapse to the same container type. All of the x3 tests pass, the code in the bug ticket passes, but the code in the OP does not. The `static_assert` still fails in detail/sequence.hpp because `sequence_size` counts the size of the sequence in the alternative to be 1: a: A, b: B, c: C, d: B, e: C -> a >> ((b >> c) | (d >> e)) : sequence<A, B, C> but sequence_size<...>::value returns 2 I _think_ this case would work too if the static_assert were updated. Also, it does not appear the alternative parser in x3 will consume `optional` with a single variant type. Lee [0]https://github.com/boostorg/spirit/commit/f16822815a08bfeb70cf75c393d05343b7a7c9f5 ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140