Re: Community Poll: What do you think about qi supporting n-ary operators?

> Am 08.08.2016 um 02:05 schrieb Frank Hein <[email protected]>:
>
>
>
> Von meinem iPad gesendet
>
>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[email protected]>:
>>
>>> On 07/08/2016 12:29 PM, Frank Hein wrote:
>>> I reworked the description of the Pull Request on Github. (
>>> https://github.com/boostorg/spirit/pull/200)
>>>
>>> For your convenience all the information from the initial post are now
>>> part of the description. I even added a bunch of new arguments and
>>> considerations for your review.
>>>
>>> I would highly appreciate any feedback. Did I miss something important? Do
>>> you want that feature? Or is it not needed or superfluos?
>>> Is my writing understandable (I am obviously not a native speaker ;). Is
>>> there something you want me to explain in more detail?
>>>
>>> Is there anybody out there?
>>
>> How about we start with a use-case? What would this facility provide that
>> the current code does not, or does so inelegantly?
>
> Points 1, 3, 5, 8 and 9 of my argument list describe what capabilities qi currently  does not provide.
>
> This PR enables the implementation of a new class of parsers, n-ary operators.
> It does not introduce any particular parser of that class. So talking about particular use cases is somewhat difficult.
>
> Anyway, I provided a link to sehe's implementation of an n-ary operator for X3, longest_match. http://coliru.stacked-crooked.com/a/cb13c1d357cdc464. This can't be done with qi currently.
>
> In other words: Implement a parser which works like qi alternative. It takes a variadic number of alternative parsers and delivers a boost::variant made from these parser's attribute types. Different to qi alternative this parser should not return the first match. It should return that match, where parsing consumed most of the input, independent of the ordering of the alternative parsers.
>
> You can not solve the whole class of problems which this particular exercise represents with qi currently. With the PR you can.

It is not completely true, that something working like that was completely impossible. But a solution would need a binary operator, which would persistently store info about it's operands. Maybe with an additional directive which takes the operator chain as an argument (a wrapper to know where the operator chain begins and ends) which has also access to the persistent context store, this could be done somehow.

But that would introduce a directive and an operator which must be used together always.  Not very clean.



> Please let us not discuss if this particular example parser is a good idea or not. That would be a different topic.
>
> Regards, Frank
>
>
>
>
>
>> Regards,
>> --
>> Joel de Guzman
>> http://www.ciere.com
>> http://boost-spirit.com
>> http://www.cycfi.com/
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Spirit-general mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/spirit-general
>>

------------------------------------------------------------------------------

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general