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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.