Re: expected_function

> Am 20.06.2016 um 11:37 schrieb Joel de Guzman <[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?
>>

Thank you for accepting the expect directive. Should I continue with the
probe directive or the operator?

I have another extension, which I would like to propose: Support for n-ary
(custom) operators. They use function style syntax, p(a, b, ...), where p
is an n-ary operator ( parser) and a, b, ... are parser expressions. To
enable this, I did some micro surgery to the heart of qi. Extended the meta
grammar by one case to handle proto::function and implemented a
make_function to create the parser. This was in the qi genes already
(use_function and appropriate generic maker function), so my change is just
a few lines of code which seamlessly integrate with qi. What do you think?
Is that a candidate for a PR?

If yes, I have an if_ ternary conditional operator which utilizes that
capability.

Regards, Frank

>> 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
> _______________________________________________
> 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.http://sdm.link/zohodev2dev

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general