Community Poll: What do you think about qi supporting n-ary operators?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein
Hello all, :)

I recently created a pull request for qi (
https://github.com/boostorg/spirit/pull/200).
Joel confirmed that coding etc is fine, but he asked me to collect
feedback from you.
The PR could be accepted, if you would find this feature/capability
valuable and
support the PR.

Subject of the PR is to add support for (custom) named n-ary operators.
With
that new parser class you could write parsers which use function style
syntax
like op(p1, ...),  where op is the name of the parser, and p1, ... is a
variadic
parameter list of parsers / parser expressions.

May I ask you to please assess the pull request, the discussion, and if
you
are deep in qi the code, also? I would highly appreciate if you respond to
this post and tell me, what you think.

Here is what I think why this PR is valuable:

Currently the only option you have to write a qi operator, is to implement
a parser and enable it using use_operator<>.

The arity is restricted to unary and binary and you have to associate
your parser with a valid C++ operator like (examples: -y, x % y).

You can not write a parser operator with an arity > 2 with qi. With this
PR
you can.

But qi already supports the nary_parser model in a way which is not per se
restricted to unary and binary operators. That means if there was way to
make
an n-ary operator recognized by qi, qi does fully support it.

This PR provides a way to make qi know about n-ary operator parsers.
Not more. The existing code base is not touched.

The number of c++ operators available is limited. So currently the maximum
number of unary parsers which can get implemented is the number of unary
c++ operators. The same applies for binary operators and binary c++
operators.

With this PR the number of possible unary and binary parsers is not
limited.

If you ever implemented a qi operator parser, you may have found, that it
is
not quite easy to select a c++ operator suitable to look expressive and
meaningful
in terms of what your parser does.

With this PR you can provide a meaningful name (even) for your unary or
binary parser.

Another topic is operator precedence. if you write a | b >> c % d, then
c++ operator
precedence applies, because this valid c++ code getting executed. If you
want
to implement a binary parser this makes the selection of an operator even
more
difficult (see
http://en.cppreference.com/w/cpp/language/operator_precedence).
Most of more interesting (with higher prio (lower number)) are already
used by qi.

With this PR you can write operators which have a precedence of 2
(function call).

Making my first dives into qi I was looking in particular for differences
between qi
and X3. I also asked Joel, if qi is going to get deprecated. He said it is
not. Therefore
it makes sense to examine X3 for interesting things qi is lacking. I found
the
expect directive was a good case to learn. I created one for qi (PR#196)
which
got accepted. Support for n-ary operators is more tricky, but it is also a
feature
X3 supports.

See this example http://coliru.stacked-crooked.com/a/cb13c1d357cdc464.
This
was gently provided by sehe as a part of one of my silly questions on
stackoverflow.

This PR closes a capability gap between qi and X3. As qi is not going to
get
deprecated, this is important to me.

Rule evaluation control: qi automatically applies rules and that works
good.
Anyway, there seems to be (have been) a demand by users to gain some
control about the rule evaluation control flow. Best example for that is
the
legendary Nabialek trick which is still referenced today.

This PR allows you to create parser which you pass a variadic number of
parsers in. Then your parser is in full control of what it does witch the
supplied
argument parsers. You could even implement your own rule application
algorithm.
In extreme: Create a parser, say my_engine, pass all your rules in
and evaluate them to your liking completely bypassing the qi rule
application
algorithm. Without loosing any of qi's features. Maybe no one would
actually
want to do that. But there are always many approaches possible to solve a
problem.
C++ offers so many different concepts to approach a problem. Control is up
to
the user. The user can decide and is not restricted to a particular
implementation.

This PR increases the options you have to approach a problem
significantly.

Do we need this enhancement? Does the parsing language get more
expressive?
The easy answer is: What is important for X3 is important for qi. If it is
true that qi
is not going to get deprecated.

Windows-MSVC: I am on that platform and in most project contexts I do not
have
the choice to switch the compiler. Enterprises with PSPGs determining the
full
tool chain. So for me, and maybe to some of you, MSVC support is
important.
X3 is not necessarily aimed at full MSVC support (i.e. see discussion
here:
https://github.com/boostorg/spirit/pull/168). I want to please ALL of my
customers
with THE SAME version of spirit. I can not afford and I do not see any
justification to
enable my people to support X3 for customers, who don't care about MSVC
and
qi for customers who do. If X3 does not support MSVC, it's a no go. So a
modern
qi is important.

This PR enhances the capabilities of qi by bringing them closer to X3,
which is
important for people on MSVC.
Risk: Please see my comment to the PR regarding risk.

So, what do you think? Thank you for the time you spent to read this. Any
feedback
would be highly appreciated.
If you want to test this, checkout the develop branch of my fork of
spirit. This is actually
the feature branch for this PR (I learned somewhat late about branching ;)
https://github.com/mxc-commons/spirit

Thank you very much. :)

Regards, Frank





------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein
When I saw how ugly this post is formatted here, I decided to repost it as
a comment
to the pull request. With minor modifications, but with an additional risk
added. :)

Please go directly to https://github.com/boostorg/spirit/pull/200. You
will find
the post nicely formatted there at the end of the conversation. Sorry.
------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

cppljevans
On 08/05/2016 10:21 PM, Frank Hein wrote:

> When I saw how ugly this post is formatted here, I decided to repost it as
> a comment
> to the pull request. With minor modifications, but with an additional risk
> added. :)
>
> Please go directly to https://github.com/boostorg/spirit/pull/200. You
> will find
> the post nicely formatted there at the end of the conversation. Sorry.
>
>

Hi Frank,

After a brief look, it looks promising; however, the code here:

https://github.com/mxc-commons/MxcQitoo/blob/master/mxc/mxc/qitoo/operator/list2.hpp

contains tabs, at least in the clone I just downloaded.
I realize this is just cosmetic; however, boost guidelines here:

http://www.boost.org/development/requirements.html#Tabs

discourage this.  You might plan on changing that eventually.

HTH.

-regards,
Larry




------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein



> Am 06.08.2016 um 17:25 schrieb Larry Evans <[hidden email]>:
>
>> On 08/05/2016 10:21 PM, Frank Hein wrote:
>> When I saw how ugly this post is formatted here, I decided to repost it as
>> a comment
>> to the pull request. With minor modifications, but with an additional risk
>> added. :)
>>
>> Please go directly to https://github.com/boostorg/spirit/pull/200. You
>> will find
>> the post nicely formatted there at the end of the conversation. Sorry.
>
> Hi Frank,
>
> After a brief look, it looks promising; however, the code here:
>
> https://github.com/mxc-commons/MxcQitoo/blob/master/mxc/mxc/qitoo/operator/list2.hpp
>
> contains tabs, at least in the clone I just downloaded.
> I realize this is just cosmetic; however, boost guidelines here:
>
> http://www.boost.org/development/requirements.html#Tabs
>
> discourage this.  You might plan on changing that eventually.

Hi Larry,

I'll change that.

But please forget about qitoo for the moment. It's about the PR for qi your oppinion would be valuable.

The Develop Branch of my fork of Spirit has the implementation. Without tabs anywhere, of course. :) Link is in the orig post.

Regards, Frank


> HTH.
>
> -regards,
> Larry
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Spirit-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/spirit-general
>

------------------------------------------------------------------------------

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


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

cppljevans
On 08/06/2016 10:43 AM, Frank Hein wrote:
>
>
>> Am 06.08.2016 um 17:25 schrieb Larry Evans <[hidden email]>:
[snip]
>> Hi Frank,
>>
>> After a brief look, it looks promising; however, the code here:
>>
>>
> https://github.com/mxc-commons/MxcQitoo/blob/master/mxc/mxc/qitoo/operator/list2.hpp
>>
>> contains tabs, ....
[snip]
> Hi Larry,
>
> I'll change that.
>
> But please forget about qitoo for the moment. It's about the PR for qi
> your oppinion would be valuable.
>
> The Develop Branch of my fork of Spirit has the implementation. Without
> tabs anywhere, of course. :) Link is in the orig post.
[snip]
OOPS.  Sorry, I missed that.
I did got to:

https://github.com/boostorg/spirit/pull/200

and clicked on the mxc-commons:develop phrase highlighted there
but that was not a link; hence, I went to:

https://github.com/mxc-commons

where I found the MxcQitoo link.  So, that's where I went wrong.
I suspect other's will go wrong for same reason.
Maybe you could make the link to actual code more obvious
somehow?  As you said, it was in the original post; however,
it was buried toward last of post.
--{--cut here--
This is actually
the feature branch for this PR (I learned somewhat late about branching
https://github.com/mxc-commons/spirit
--}--cut here--

-regards,
Larry








------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein
Larry Evans <[hidden email]> wrote on 06.08.2016 20:31:19:

> From: Larry Evans <[hidden email]>
> To: [hidden email],
> Date: 06.08.2016 20:33
> Subject: Re: [Spirit-general] Community Poll: What do you think
> about qi supporting n-ary operators?
>
> On 08/06/2016 10:43 AM, Frank Hein wrote:
> >
> >
> >> Am 06.08.2016 um 17:25 schrieb Larry Evans
<[hidden email]>:

> [snip]
> >> Hi Frank,
> >>
> >> After a brief look, it looks promising; however, the code here:
> >>
> >>
> > https://github.com/mxc-commons/MxcQitoo/blob/master/mxc/mxc/qitoo/
> operator/list2.hpp
> >>
> >> contains tabs, ....
> [snip]
> > Hi Larry,
> >
> > I'll change that.
> >
> > But please forget about qitoo for the moment. It's about the PR for qi
> > your oppinion would be valuable.
> >
> > The Develop Branch of my fork of Spirit has the implementation.
Without

> > tabs anywhere, of course. :) Link is in the orig post.
> [snip]
> OOPS.  Sorry, I missed that.
> I did got to:
>
> https://github.com/boostorg/spirit/pull/200
>
> and clicked on the mxc-commons:develop phrase highlighted there
> but that was not a link; hence, I went to:
>
> https://github.com/mxc-commons
>
> where I found the MxcQitoo link.  So, that's where I went wrong.
> I suspect other's will go wrong for same reason.
> Maybe you could make the link to actual code more obvious
> somehow?  As you said, it was in the original post; however,
> it was buried toward last of post.
> --{--cut here--
> This is actually
> the feature branch for this PR (I learned somewhat late about branching
> https://github.com/mxc-commons/spirit
> --}--cut here--
>
> -regards,
> Larry
>
Larry, I corrected the things you mentioned. Thank you.

Just to make sure we have a common understanding of what this poll is all
about:

To contribute to qi, I had to create a fork of boostorg/spirit. This fork
is mxc-commons/spirit. New features, bug fixes etc I can do in my fork.
This does not change anything to boostorg/spirit.

When I think, something is good enough and valuable enough I propose it
to Joel by creating a so called Pull Request. Having that done, the new
code is still not part of qi. Joel now can accept or reject the pull
request. Only if he accepted it would get part of qi.

Current status: I implemented and tested an extension to qi, which enables
support for n-ary operators. I created a pull request for that. The pull
request is not accepted yet. https://github.com/boostorg/spirit/pull/200

As long as the PR is not accepted, this feature will not be part of qi.
If it would get accepted, qi would get the feature. The magic of Github
Pull Requests makes this happen.

If you read the comments, Joel asked me to drum for support. He wants to
know, if the community would like have this feature in qi.

That's what the poll is about. Do you think, qi should support n-ary
operator parser? Should this feature be added to qi? If yes, why?
If no, why not? Do you have an oppinion to that you want to share?

Regards, Frank
------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein
In reply to this post by Frank Hein
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?

Cheers, Frank
------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Joel de Guzman
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?

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein


Von meinem iPad gesendet

Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email]>:

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. 

Please let us not discuss if this particular example parser is a good idea or not. That would be a different topic. 

Regards, Frank





Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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


------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein

Am 08.08.2016 um 02:05 schrieb Frank Hein <[hidden email]>:



Von meinem iPad gesendet

Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email]>:

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. 

Regards, Frank





Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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


------------------------------------------------------------------------------

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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Joel de Guzman
On 08/08/2016 8:24 AM, Frank Hein wrote:

>
> Am 08.08.2016 um 02:05 schrieb Frank Hein <[hidden email]
> <mailto:[hidden email]>>:
>
>>
>>
>> Von meinem iPad gesendet
>>
>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email] <mailto:[hidden email]>>:
>>
>>> 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]

which IMO, is cleaner. Granted, "cleaner" is a subjective term. Anyway, use-cases
always make concepts clearer. It is difficult to discuss any subject in purely
abstract terms.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein




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 [hidden email]
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


Von meinem iPhone gesendet
Am 08.08.2016 um 07:33 schrieb Joel de Guzman <[hidden email]>:

On 08/08/2016 8:24 AM, Frank Hein wrote:

Am 08.08.2016 um 02:05 schrieb Frank Hein <[hidden email]
<[hidden email]>>:



Von meinem iPad gesendet

Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email] <[hidden email]>>:

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. 

With the PR the implementation of longest(a,b,c) is a just a few lines of code (beyond the usual boilerplate to make that a function parser).  

which IMO, is cleaner. Granted, "cleaner" is a subjective term. Anyway, use-cases
always make concepts clearer. It is difficult to discuss any subject in purely
abstract terms.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Joel de Guzman
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 [hidden email] <mailto:[hidden email]>
> 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 <[hidden email] <mailto:[hidden email]>>:
>
>> On 08/08/2016 8:24 AM, Frank Hein wrote:
>>>
>>> Am 08.08.2016 um 02:05 schrieb Frank Hein <[hidden email]
>>> <mailto:[hidden email]>
>>> <mailto:[hidden email]>>:
>>>
>>>>
>>>>
>>>> Von meinem iPad gesendet
>>>>
>>>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email]
>>>> <mailto:[hidden email]> <mailto:[hidden email]>>:
>>>>
>>>>> 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
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein


Von meinem iPhone gesendet
> Am 09.08.2016 um 00:12 schrieb Joel de Guzman <[hidden email]>:
>
>> 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 [hidden email] <[hidden email]>
>> 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 <[hidden email] <[hidden email]>>:
>>>
>>>> On 08/08/2016 8:24 AM, Frank Hein wrote:
>>>>
>>>> Am 08.08.2016 um 02:05 schrieb Frank Hein <[hidden email]
>>>> <[hidden email]>
>>>> <[hidden email]>>:
>>>>
>>>>>
>>>>>
>>>>> Von meinem iPad gesendet
>>>>>
>>>>> Am 07.08.2016 um 22:40 schrieb Joel de Guzman <[hidden email]
>>>>> <[hidden email]> <[hidden email]>>:
>>>>>
>>>>>>> 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.
>

As far as I understand it, a directive is somerhing that modifies the environment a parser runs in. It can be used to preprocess input, postprocess output, force consecutive runs and so on. The parser implements the parsing logic/algorithm. The directive apapts a parser for a particular application. Is that understanding wrong? Doc explained: " directives (are)... usable to augment and parameterize other parsers."

My notion of "clean" means, that all qi components should be self-contained. The common interface is parser member function. Qi follows this paradigm strictly and I love that. The user so can define a parser knowing exactly what he gets, because there are no hidden side effects from components having private talks.

For me it was important to maintain that paradigm (for consistency reasons to aasige predictable behaviour under all ciecumstances.


FP = Functional Programming?

As far as I can see, there are no "such things" (n-ary operators) in qi so far.


> 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
> _______________________________________________
> Spirit-general mailing list
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Community Poll: What do you think about qi supporting n-ary operators?

Frank Hein

Sorry for the typos. aasige = assure. aasige is not even a German word.

F**k spell checker. :(



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general


smime.p7s (6K) Download Attachment