Re: Community Poll: What do you think about qi supporting n-ary operators?
Joel de Guzman <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
On 09/08/2016 1:00 AM, Frank Hein wrote: > > > > > Frank Hein > > Geschäftsführer > maxence business consulting gmbh > > phone +49-(0)-2133-2599-0 > fax +49-(0)-2133-2599-29 > cell +49-(0)-151-54 74 29 89 > internet [email protected] <mailto:[email protected]> > skype fhmaxence > > Am Weißen Stein 1 > Stürzelbergcenter > D - 41541 Dormagen > Sitz der Gesellschaft: Dormagen > Handelsregister: HRB 8966, Neuss > Geschäftsführer: Dipl.-Inform. Frank Hein > www.maxence.de <http://www.maxence.de/> > > Von meinem iPhone gesendet > Am 08.08.2016 um 07:33 schrieb Joel de Guzman <[email protected] <mailto:[email protected]>>: > >> 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]> >>> <mailto:[email protected]>>: >>> >>>> >>>> >>>> Von meinem iPad gesendet >>>> >>>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[email protected] >>>> <mailto:[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] >> > That would would not work with the qi alternative operator, because it returns the first > match. You'd have to implement a new one working together with longest. > > And isn't > > longest[a | b | c] > > somewhat sophisticated to understand compared to > > longest(a, b, c)? > > What does the operator in your example do what's not already expected to be done by longest? > > Is max[a+b+c+d] ( or max[a|b|c|d] if you like) a better expression then max(a,b,c,d), if > you want the maximum of these four values? Just to illustrate. Well, the directive *is* the syntax of choice used by Spirit for such things from the very start. Consistency matters. max(a, b) is consistent in its domain. One can also argue that alternative(a, b, c) is consistent in the FP domain. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/ ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev