On Sunday, February 28, 2016 7:15 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Le 02/03/2016 03:57, Steven Watanabe a écrit :

AMDG

On 02/28/2016 06:15 AM, Vicente J. Botet Escriba wrote:

...

Le 27/02/2016 17:41, Steven Watanabe a écrit :

...

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.

<snip>

P.S. Paul, maybe you can add something about this in the documentation of infix.

That's all I was getting at. Sure, I can work out what happens, but I'd be happier if the documentation showed some indication that the author had considered the issue, and found (a) there's nothing to worry about, it will always work correctly, or (b) it can only cause problems in some obscure circumstances. Also, if the user makes a mistake, how confused can the compiler get?

I'd also like some explanation of how it interacts with other kinds of trickiness:

- phoenix::_1 <plus> phoenix::_2 - BOOST_TEST(1 <plus> 2);

Paul, do you have something to add? Vicente

Le 27/02/2016 20:18, Edward Diener a écrit :

On 2/27/2016 11:16 AM, Vicente J. Botet Escriba wrote:

...

Dear Boost community,

The formal review of Paul Fultz II's Fit library starts on Wednesday, 2nd March and ends on 13th March.

What is the branch of Fit we are going to be reviewing ?

The boost branch. The link https://github.com/pfultz2/Fit/tree/boost points directly to the repository that will be reviewed. Vicente

On Sunday, February 28, 2016 12:23 PM, Edward Diener <eldiener@tropicsoft.com> wrote:

On 2/27/2016 11:16 AM, Vicente J. Botet Escriba wrote:

...

Dear Boost community,

The formal review of Paul Fultz II's Fit library starts on Wednesday, 2nd March and ends on 13th March.

How do I generate the docs or run the tests for my local copy of Fit ?

You can build and run the tests by building the check target. For those unfamiliar with cmake, first configure the build directory with cmake: mkdir build cd build cmake .. cd .. Next build the check target using the native build system(such as make or msbuild). CMake can call the native build system to build the target 'check', like so: cmake --build build --config Release --target check Also, the library can be installed by invoking the 'install' target. The documentation needs to be built using mkdocs. You can install mkdocs and the boost theme with pip like this: pip install mkdocs mkdocs-boost Then to build the documentation, first `setup.py` must be run to extract the documentation and examples from the source code, then `mkdocs` can be invoked, like this: python setup.py mkdocs build -t boost And the documentation will be in the 'doc/html' directory. Paul

On Sunday, February 28, 2016 at 6:12:22 PM UTC-6, Matt Calabrese wrote:

On Sat, Feb 27, 2016 at 8:16 AM, Vicente J. Botet Escriba < vicent...@wanadoo.fr <javascript:>> wrote:

...

Dear Boost community,

The formal review of Paul Fultz II's Fit library starts on Wednesday, 2nd March and ends on 13th March.

I'm looking through the documentation right now and it looks great, though I have not used the library yet. Some suggestions -- I think the docs really need a more formal motivation/tutorial section at the very front. It starts with *what* the library is in very general terms, and jumps quickly into what the library can do, but I think a bit of a narrative describing a motivating example would help sell it to those who are not already more familiar with the *why*. This is done a little bit, scattered throughout the docs, but I find that the best docs usually tell something of a story. This is just a request.

Do you have an idea of what kind of problem would make a good motivating example for this library? The quick start guide moves quickly so people can quickly see what the library can do. However, a more in-depth turtorial could be useful as well. I just need to think of a larger problem that stays focus on the functional aspect.

I suggest not using the name FunctionObject for something that is only callable with a const object. This is a little more specific that what most people refer to as a function object in C++ and may cause confusion.

Good point. This would also apply to Callable as well.

I'm fairly certain that the reinterpret casting involved with BOOST_FIT_STATIC_LAMBDA is UB.

Not really, since the objects are empty, there is no data access. I have a static assert to guard against this restriction. Also, on gcc and clang with BOOST_FIT_STATIC_LAMBDA_FUNCTION, the reinterpret cast happens at compile- time. Now there could be an insane implementation where this doesn't work(perhaps the lambdas are not empty for some strange reason), which the library would have to apply a different technique to make it work. However, this is quite unlikely considering that C++ will probably get constexpr lambdas and inline variables in the future. Paul