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

On 08/08/2016 8:24 AM, Frank Hein wrote:
>
> Am 08.08.2016 um 02:05 schrieb Frank Hein <[email protected]
> <mailto:[email protected]>>:
>
>>
>>
>> Von meinem iPad gesendet
>>
>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[email protected] <mailto:[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.

I'm not sure about that. I always preferred:

    longest[a | b | c]

which IMO, is cleaner. Granted, "cleaner" is a subjective term. Anyway, use-cases
always make concepts clearer. It is difficult to discuss any subject in purely
abstract terms.

Regards,
-- 
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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