Re: [Spirit Qi %] (x%y) not semantically equivalent to (x >> *(y >> x))
Frank Hein <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
> Am 29.05.2016 um 17:31 schrieb Lee Clagett <[email protected]>: > > On Sat, 28 May 2016 02:36:42 +0200 > Frank Hein <[email protected]> wrote: > >> With the current implementation expected parser output gets discarded >> when used with %. Allthough >> it is documented as you pointed out this is somewhat strange at least. >> >> You are right, a fix would break int_ % char_(",;"). >> >> But if you don't want the char_(",;") attribute I would recommend to >> use lit instead of char_. > > Yes, if the behavior of the list parser were changed everyone using it > could adapt. But why should everyone be required to review their usage > of the list operator because you want the attribute for the separator > exposed? No, you were right. The char_(",;") functionality would be discarded without replacement. I did not see that first. lit works different to char_. Something like lit_char_ would be needed to to be able to model the current behaviour with a modified %. I think this would be inappropriate. >> Often enough if happened, that bugs became features for good reasons. >> I do not know if this >> is justified here. The use of % gets significantly limited for the >> sake of what? >> >> Frank > > If the list parser does not meet your expectations or needs, then it is > an inconvenience to you but not necessarily a "bug that became a > feature". Joel has not said anything specifically about this topic, but > I am fairly certain the intent of the list parser was to omit the > separator from the exposed attribute. In the majority of cases > the separator value is irrelevant. For cases where this is not true, > the more verbose way of producing the identical parser is still > available. > It is an inconvenience, not more. I just wanted to help because I thought I found a bug in the core. I was wrong. Spirit parser implementation is more or less straight-forward once you get confident with the mechanism to integrate them without polluting the qi namespace. So I can add what I need without changing qi. Frank > Lee > > ------------------------------------------------------------------------------ > 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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > Spirit-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/spirit-general > ------------------------------------------------------------------------------ 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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Spirit-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spirit-general
smime.p7s
(application/pkcs7-signature, 5.1 KB) - not displayed