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

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