Re: expected_function
Joel de Guzman <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
On 18/06/2016 7:47 PM, Frank Hein wrote:
>> We can probably do it in separate PRs, starting with the expect directive
>> perhaps?
>
> That's a good point to start with for me to get confident with the procedures. I'd fork
> spirit, add the operator, move it into the qi namespace, adjust example and test.
> Regarding the docs I'll have to look how they are done. I'll take the existing directives
> doc as a spec. Ok so far?
Sounds good!
>> That way, we can do a thorough review. Also, I'm not yet sure if
>> all the additional components can make it into the codebase. expect is
>> definitely an important addition. probe is interesting, but I'm not 100%
>> sure about what it really is and its significance.
>
> Probe does in effect the same as the existing hold directive. It does attribute rollback
> if the expression fails to parse. Hold accomplishes that by creating a temporary attribute
> and swapping that in on success. So it requires swap to be implemented for the attribute
> type.
>
> Probe on the other hand does not produce a temporary atrribute. It parses lookahead once
> and on success a second time producing the attribute. No swap implementation necessary. So
> it can be savely applied even on intermediates like expr >> hold[expr] without having the
> intermediate attribute type explicitly defined.
>
> Pro hold: Parses once, no buffering, speed
> Inconvenience: Swap impl. necessary
> Effort: Parse (fail), parse + swap ( success)
>
> Pro probe: No swap, applicable to intermediates
> Cons: Lookahead
> Effort: Parse ( fail), parse twice (success)
>
> Probe is easier to use, so in parser development probe could be the choice, while the
> final runtime optimized version would employ hold.
OK, I get it. I don't quite understand though why it is easier to use?
>> operator / would be
>> quite useful in certain contexts, but it can already be done using some
>> other means, no?
>
> It can be done otherwise. id / string("::") can be expressed as id >> *(string("id") >> id).
> / can parse a superset of %. So is id % expr the same as id / omit[expr]. / does attribute
> rollback on failure.
>
>> I'll also have to ask you to maintain your code and provide support for
>> it. Oh and the docs will have to be properly integrated, just like any
>> other component in Qi. So, in the end, it won't be an easy ride for you,
>> but if you are willing to go the whole nine yards, then I am all for it.
>
> Ok. My time is dedicated to tec research alone nowerdays. Live is a joy. :) That's not all
> about parsing but I am willing to put effort in this.
>
>> How about we go try it out with expect directive first? That is an easy
>> one.
>
> Yes, sure. Are the steps described above correct?
Correct.
> I have some other things ready, but I did not manage to finalize the docs and tests before
> my vacation began. I am back in July. I extended qi to support operators of higher arity.
> A ternary conditional operator called if_ is available. This enables for example the
> Nabialek trick (just without trick). I think, qitoo is a nice test bed for such proposals.
>
> Looking forward to start. :)
Wonderful! Seems you know your way around Qi!
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/zohomanageengine