Re: [Boost-users] [Fit] upcoming formal review for Boost.Fit

Subject: Re: [Boost-users] [Fit] upcoming formal review for Boost.Fit
From: paul Fultz (pfultz2_at_[hidden])
Date: 2016-02-28 12:48:23

On Sunday, February 28, 2016 7:15 AM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:

>
>
>Le 27/02/2016 17:41, Steven Watanabe a écrit :
>> AMDG
>>
>> On 02/27/2016 09:16 AM, Vicente J. Botet Escriba wrote:
>>> The formal review of Paul Fultz II's Fit library starts on Wednesday,
>>> 2nd March and ends on 13th March.
>>>
>>> Fit is a header-only C++11/C++14 library that provides utilities for
>>> functions and function objects.
>>>
>> constexpr infix_adaptor<plus_f> plus = {};
>> int r = 3 <plus> 2;
>>
>>    This is clever idea, but I'd really like to
>> see an analysis of how it interacts with
>> operator precedence.
>>
>>
>You should consider the normal precedence for operator<() and 
>operator>() and use parenthesis when you are not sure what will be the 
>result ;-) There is no magic.
>
>Idealy I would like that we can use a different symbol to enclose the 
>function name e.g;the back-quote  '`' which is not used now and have 
>left associativity with the highest precedence, but this is not possible 
>now and would very probably never be :(
>
>I found it useful e.g. if you have a binary function
>
>     mbind(Monad, Callable) -> Monad
>
>Using the infix notation allows to chain the continuations in a more 
>natural way
>
>     m <mbind> []() {....}  <mbind> []() {....}
>
>instead of
>
>     mbind(mbind(m, []() {....}), []() {....} );
>
>What is terrible is that the following (I believe) will work also :(
>
>     m < mbind > []() {....}  < mbind > []() {....}

>

Yes it is designed to easily chain the operations together.

    x <op> y <op> z

>and also that :( :(
>
>     ((m <   mbind)    > []() {....}  <   mbind)     > []() {....}
>
>Of course we don't want to write code like this one, but ...
>
>With the first proposal of uniform call syntax we were able to have 
>something similar
>
>     m.mbind(f).mbind.(g);
>

>but this equivalence has not been retained for the time been.
>

But that can be achieved using pipable functions:

    m | mbind(f) | mbind(g)

>So I could summarize the infix adaptor is just syntactic sugar that 

>doesn't respond completlly to my final goal, and should be used sparsely.
>

For most cases, I found pipable functions work much better to achieve the
goal. The only advantage of an infix operator is lack of parenthesis, but I
have never found it to be too much an issue.

Finally, Boost.Hana uses the ^ operator to achieve infix notation instead.
Ideally, I could create a decorator such as `infix_with` that could set the
type of operator to use with infix notation, because sometimes the user may
want to control precedence. However, I would like to see how widely this would
be used before taking on such an endeavor. Currently it is only used in a few
instances that don't need this type of customization.

>Vicente
>
>P.S. Paul, maybe you can add something about this in the documentation 
>of infix.
>
>_______________________________________________
>Boost-users mailing list
>Boost-users_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>