[review][Fit] Review of Fit starts today : September 8 - September 17
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote. This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ==================== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions. Requirements This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support: Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs. Noexcept support: On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ==================== Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Matt Calabrese via Boost [boost@lists.boost.org] Sent: 08 September 2017 12:02 To: Boost Developers List Cc: Matt Calabrese Subject: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
.....
This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here:
In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed.
I looked at the previous review and found the following: ----------------------------------------------- Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. ------------------------------------------------ Is that detailed report available somewhere please? Thanks John Fletcher
On Sep 8, 2017, at 7:04 AM, Fletcher, John P via Boost <boost@lists.boost.org> wrote:
I looked at the previous review and found the following:
----------------------------------------------- Detailed Report ===============
You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues.
------------------------------------------------
Is that detailed report available somewhere please?
No, a detailed report was never published.
________________________________________ From: P F [pfultz2@yahoo.com] Sent: 08 September 2017 14:06 To: boost@lists.boost.org Cc: Fletcher, John P Subject: Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
Is that detailed report available somewhere please?
No, a detailed report was never published.
Oh well. I have just started to look at this in comparison with some examples I made with a version downloaded in February 2017. I have not found any list of the changes. I have noted the following. 1. Change namespace to boost::fit 2. Relocation of header files 3. Add BOOST_ to macro names. All of those I expected. Also two of the examples I had done no longer work as "compress" and "reverse_compress" have disappeared. Have they been renamed to something else or removed completely? Are there any other changes please? Best wishes John
On Fri, 2017-09-08 at 15:14 +0000, Fletcher, John P wrote:
________________________________________ From: P F [pfultz2@yahoo.com] Sent: 08 September 2017 14:06 To: boost@lists.boost.org Cc: Fletcher, John P Subject: Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
Is that detailed report available somewhere please?
No, a detailed report was never published.
Oh well. I have just started to look at this in comparison with some examples I made with a version downloaded in February 2017. I have not found any list of the changes. I have noted the following.
1. Change namespace to boost::fit 2. Relocation of header files 3. Add BOOST_ to macro names.
All of those I expected.
Also two of the examples I had done no longer work as "compress" and "reverse_compress" have disappeared.
Have they been renamed to something else or removed completely?
These have been renamed to `fold` and `reverse_fold`.
Are there any other changes please?
There are no other breaking changes. Other changes have been improvements to take advantage of C++17 features where possible, support for msvc 2017, more testing was added, some documentation improvements, and some minor fixes. .
Le 08/09/2017 à 14:04, Fletcher, John P via Boost a écrit :
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Matt Calabrese via Boost [boost@lists.boost.org] Sent: 08 September 2017 12:02 To: Boost Developers List Cc: Matt Calabrese Subject: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. .....
This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. I looked at the previous review and found the following:
----------------------------------------------- Detailed Report ===============
You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues.
------------------------------------------------
Is that detailed report available somewhere please?
Hi, I'm really sorry. I didn't take the time to write such a report :( My apologies. Vicente
On Fri, Sep 8, 2017 at 6:02 AM, Matt Calabrese via Boost < boost@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
[snip]
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I vote to accept Fit. I would like to see some naming changes, but I'm not making any of them conditions for acceptance, because I do not consider any of them to be deal-breakers. Some other questions you might want to consider answering:
- What is your evaluation of the design?
(Still) good. Here's what I wrote in the last review: I particularly like the fact that it attempts to keep everything constexpr- and SFINAE-friendly wherever possible. I *really* like reveal() and failure(). Too few TMP-heavy libraries pay attention to providing good error messages. I have no problem with the constness requirements on Callables used throughout Fit, as was discussed previously. I even consider this a feature, allowing me to detect non-const Callables, which are almost always an error on my part. This is especially true since std::ref() and mutable_() let me explicitly choose how to handle mutable Callables, in a way that is also explicit at the call site. There are a number of adaptors that I find have obscure names: by() is a projection; why not call it project()? flow() is a super obscure name! Why is this not reverse_compose() or similar? indirect() could more easily be understood if it were called deref() or dereference(). I don't feel as strongly about partial(), but I think it might be clearer if it were called partial_apply() or curry(). conditional() should be called invoke_first(), call_first_of(), or similar. I find it too easy to confuse with if_(). For that matter, it would be nice if "if_()" were called "if_constexpr()", since that seems to match its semantics, and since there's a language feature that already does this; a reader of uses of "if_constexpr()" will get the intent faster than they would if they read "if_()".
- What is your evaluation of the implementation?
I did not look at it much, but what I did look at had no readily apparent issues.
- What is your evaluation of the documentation?
It has gotten dramatically better since the last review. The non-reference sections now provide a thorough tour of the library and its capabilities. I took issue with some of the reference docs in the last review; those have all been addressed.
- What is your evaluation of the potential usefulness of the library?
I think the library is very useful. For example, I had to do some somewhat hairy overload-resolution metaprogramming in an expression template library I've been working on, and I really wished conditional() were already in Boost so I could have used it instead.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
I did this quite a bit the first time around, and it was very easy to use the part I care about the most (conditional()), using Clang 3.6. The same code works fine with Clang 4, but I did not do anything with the new version of the library more than what I did with the old one. - How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
I spent 5-6 hours on the first review, and about 2 hours this time.
- Are you knowledgeable about the problem domain?
Yes. I do a lot of generic programming.
- Were the concerns from the March 2016 review of Fit addressed?
Many of them were. The only ones that were not were related to naming, as repeated above. As I said, I don't consider any of those naming choices to be blockers, just suboptimal. Zach
On Mon, 2017-09-11 at 11:55 -0500, Zach Laine via Boost wrote:
On Fri, Sep 8, 2017 at 6:02 AM, Matt Calabrese via Boost < boost@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
[snip]
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I vote to accept Fit. I would like to see some naming changes, but I'm not making any of them conditions for acceptance, because I do not consider any of them to be deal-breakers.
Thanks, Zach, for the review.
Some other questions you might want to consider answering:
- What is your evaluation of the design?
(Still) good. Here's what I wrote in the last review:
I particularly like the fact that it attempts to keep everything constexpr- and SFINAE-friendly wherever possible.
I *really* like reveal() and failure(). Too few TMP-heavy libraries pay attention to providing good error messages.
I have no problem with the constness requirements on Callables used throughout Fit, as was discussed previously. I even consider this a feature, allowing me to detect non-const Callables, which are almost always an error on my part. This is especially true since std::ref() and mutable_() let me explicitly choose how to handle mutable Callables, in a way that is also explicit at the call site.
There are a number of adaptors that I find have obscure names:
by() is a projection; why not call it project()?
by() is not a projection, rather it takes a projection. I mainly named it for how it was used, so it would read more english-like: std::sort(std::begin(people), std::end(people), by(&Person::year_of_birth, _ < _)); Like "sort by year_of_birth". In haskell, its called 'on', but it seems 'by' is more natural for English.
flow() is a super obscure name! Why is this not reverse_compose() or similar?
Its because its used with pipable. So it can take a set of pipable functions so they "flow" together. reverse_compose() could work, but I think the name looks clunky as an alternative to pipable functions. Also, in haskell there is no reverse compose(just `.` for composition), instead the `>>>` arrow operator can be used to indicate the direction of composition, but there is no way to implement such an operator in C++.
indirect() could more easily be understood if it were called deref() or dereference().
This named after the indirect in the Ranges library. Also, I might add a custom operator in the future, so calling it deref might not make sense.
I don't feel as strongly about partial(), but I think it might be clearer if it were called partial_apply() or curry().
Which there could be an uncurry function, but I've always understood curry to be for one arg at a time. Either waty, I could provide curry for repeated partial applications(ie what partial is currently). Then provide partial and reverse_partial like hana for a single partial application. I just wonder if this bloats the interface, as we will have a lot of different functions for partial application.
conditional() should be called invoke_first(), call_first_of(), or similar. I find it too easy to confuse with if_().
I could call it first_of(). I do see the confusion with `std::conditional`.
For that matter, it would be nice if "if_()" were called "if_constexpr()", since that seems to match its semantics, and since there's a language feature that already does this; a reader of uses of "if_constexpr()" will get the intent faster than they would if they read "if_()".
To work like if_constexpr(), eval() would needed to be used. There are of course other ways to use it(especially in point-free programming) that is not an emulation of `if constexpr`, like how I implement `yield_if` here: https://github.com/pfultz2/Hero/blob/master/include/hero/for_each.h#L43
- What is your evaluation of the implementation?
I did not look at it much, but what I did look at had no readily apparent issues.
- What is your evaluation of the documentation?
It has gotten dramatically better since the last review. The non-reference sections now provide a thorough tour of the library and its capabilities.
I took issue with some of the reference docs in the last review; those have all been addressed.
- What is your evaluation of the potential usefulness of the library?
I think the library is very useful. For example, I had to do some somewhat hairy overload-resolution metaprogramming in an expression template library I've been working on, and I really wished conditional() were already in Boost so I could have used it instead.
Well, hopefully it will be there soon. Thanks, Paul
On 9/8/2017 7:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review.
And that branch is ... ?
You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote.
This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php
In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed.
The following is a brief description of the library from its author:
====================
Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming.
Fit is:
Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface.
Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more.
Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components:
Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions.
Requirements
This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.
Contexpr support:
Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs.
Noexcept support:
On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this.
====================
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
Some other questions you might want to consider answering:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed?
More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html
Thank you for participating!
On Sep 13, 2017, at 7:47 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 9/8/2017 7:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review.
And that branch is … ?
Its the branch boost. Thats what the source links to.
Here is my review of the FIT library
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I vote to ACCEPT FIT as a Boost library.
Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation?
I have found both the design and the implementation to be consistent and well carried through. There are a few things which are in the detail which are in fact of use to users and it would be helpful it they were available in the fit namespace. See notes below.
- What is your evaluation of the documentation?
The general standard of the reference documentation is good. It would help to have some more examples. There are some things which are not documented such as alias and the configuration. Also move and forward which are in detail although useful to users. - What is your evaluation of the potential usefulness of the library? I think this is a very useful library. I have explored this by building an example use - see notes below. - Did you try to use the library? With which compiler(s)? Did you have any problems? Yes, I have built examples to run everything I can find in the library. I did this with the version available in February this year and have moved the examples over to the Boost version with the necessary changes to namespace and boostification of the macros. All worked after I found the name changes to compress/reverse compress to fold/reverse_fold. I see that this is a response to previous discussion and I agree with the changes. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have been working with FIT for some time and building the examples. I have mainly used various versions of clang and libc++, also using various versions of gcc. I have discovered that not all of the compiler configuration is carried out in fit/configure.hpp. The following headers also detect the compiler being used: alias, always, implicit, pack, reveal, unpack. I have built examples of all of the code I can find, including for alias where there is no documentation and only test examples for some of the things in the header. It is used in pack and combine and may have been intended to be internal although it can be used externally. In some of the examples I have combined FIT with boost function and boost phoenix - Are you knowledgeable about the problem domain? I have been able to compare the operations of FIT with other implementations of similar code and found that FIT can go far beyond what was possible using C++. I have been active in this area for longer that I care to remember (> 10 years). - Were the concerns from the March 2016 review of Fit addressed? This is hard to answer as I could not find the full report on the first review. I think that it is the case.
Thank you for participating!
Thank you Paul for the library. I look forward to making use of it. Best wishes John Fletcher
On Fri, 2017-09-15 at 10:48 +0000, Fletcher, John P via Boost wrote:
Here is my review of the FIT library
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I vote to ACCEPT FIT as a Boost library.
Thanks, for the review.
Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation?
I have found both the design and the implementation to be consistent and well carried through. There are a few things which are in the detail which are in fact of use to users and it would be helpful it they were available in the fit namespace. See notes below.
- What is your evaluation of the documentation?
The general standard of the reference documentation is good. It would help to have some more examples.
What kind of more examples would you like to see?
There are some things which are not documented such as alias and the configuration. Also move and forward which are in detail although useful to users.
- What is your evaluation of the potential usefulness of the library?
I think this is a very useful library. I have explored this by building an example use - see notes below.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
Yes, I have built examples to run everything I can find in the library. I did this with the version available in February this year and have moved the examples over to the Boost version with the necessary changes to namespace and boostification of the macros. All worked after I found the name changes to compress/reverse compress to fold/reverse_fold. I see that this is a response to previous discussion and I agree with the changes.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I have been working with FIT for some time and building the examples. I have mainly used various versions of clang and libc++, also using various versions of gcc. I have discovered that not all of the compiler configuration is carried out in fit/configure.hpp. The following headers also detect the compiler being used: alias, always, implicit, pack, reveal, unpack.
Some of those is because there is no specific compiler feature it is working around. Although in a few places I could use another config.
I have built examples of all of the code I can find, including for alias where there is no documentation and only test examples for some of the things in the header. It is used in pack and combine and may have been intended to be internal although it can be used externally.
It is intended to be used externally, which is why there is an initial documentation, and it is not in the detail namespace. Many didn't see how it is related to this library, plus it was missing a useful example. So for now, I just took it out of the TOC, but would like to add it back, but need a good motivating example. Thanks, Paul
On 9/8/17 4:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
I'm beginning to take a look at the documentation and immediatly I have question: How does this contrast with recently accepted Boost.CallableTraits and Boost.FunctionTypes? Reading the introduction About and Motivation I would like to see a simple example of a problem solved by the library. I should be enough to make me want to investigate the library further or help me decide that it's not a good fit for what I want to do. I don't like names like Fit which give no helpful information. But I've lost that battle before so I won't belabor this any more. Robert Ramey
On 9/15/17 11:45 AM, Robert Ramey via Boost wrote: I much like the "Getting Started" page- it's really helpful and clearly presented. So maybe my critcism came off harsher than it should be. Robert Ramey
On Sep 15, 2017, at 1:45 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 9/8/17 4:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
I'm beginning to take a look at the documentation and immediatly I have question:
How does this contrast with recently accepted Boost.CallableTraits and Boost.FunctionTypes?
Those seems more about querying properties about functions, which is different than the Fit library. Although, the Fit library does provide a `is_callable` trait which is similar to `is_invocable` in CallableTraits, but Fit implements this without using substitution failure on MSVC because it is problematic.
Reading the introduction About and Motivation I would like to see a simple example of a problem solved by the library. I should be enough to make me want to investigate the library further or help me decide that it's not a good fit for what I want to do.
I don't like names like Fit which give no helpful information. But I've lost that battle before so I won't belabor this any more.
True, I really like Vicente’s suggestion of HigherOrderFunctions. .
On 15. Sep 2017, at 20:45, Robert Ramey via Boost <boost@lists.boost.org> wrote:
I don't like names like Fit which give no helpful information. But I've lost that battle before so I won't belabor this any more.
I would like to join the chorus of people who don't like the name "Fit". Please - please - consider changing this. "Fit", what does it mean? Is it an acronym (perhaps for function interface toolkit??)? Was the library written in a "fit" of rage over the lack of proper tools? Is the library in particular good health, perhaps? The documentation does not tell us, but even if it would, a longer, more descriptive name would be helpful. In my personal professional context, a "fit" refers to code that adapts a statistical model to stochastic data by minimising a cost function, which somehow measures the closeness of the model and the data. Googling "c++ fit library" yields links to Boost.Fit, but the first other hits are related to such optimisation libraries (this is not because of my personal Google search bubble, I used a private browser session). This as another hint that the name "Fit" is misleading. If I may suggest a name: I like description on github "function utility library". So what about "Function Utilities", which is quite descriptive. On the Boost library page it would be inserted next to "Function" and "Function Types", which - ironically - seems quite "fit"ting. PS: Googling "fit library" yields such curious results as "Fashion Institute of Technology" in NYC and the "Florida Institute of Technology" (both have a library). :) Best regards, Hans
On Mon, 2017-09-18 at 12:10 +0200, Hans Dembinski via Boost wrote:
On 15. Sep 2017, at 20:45, Robert Ramey via Boost <boost@lists.boost.org> wrote:
I don't like names like Fit which give no helpful information. But I've lost that battle before so I won't belabor this any more.
I would like to join the chorus of people who don't like the name "Fit". Please - please - consider changing this.
"Fit", what does it mean? Is it an acronym (perhaps for function interface toolkit??)?
I was going for function utility library, which makes FUL, and I didnt like that acronym(although it is the first three letters of my name) as it could sound big and bloated. So I went with Fit, because it sounds much "healthier", and I thought I could backronym it at some point.
Was the library written in a "fit" of rage over the lack of proper tools? Is the library in particular good health, perhaps? The documentation does not tell us, but even if it would, a longer, more descriptive name would be helpful.
In my personal professional context, a "fit" refers to code that adapts a statistical model to stochastic data by minimising a cost function, which somehow measures the closeness of the model and the data. Googling "c++ fit library" yields links to Boost.Fit, but the first other hits are related to such optimisation libraries (this is not because of my personal Google search bubble, I used a private browser session). This as another hint that the name "Fit" is misleading.
If I may suggest a name: I like description on github "function utility library". So what about "Function Utilities", which is quite descriptive. On the Boost library page it would be inserted next to "Function" and "Function Types", which - ironically - seems quite "fit"ting.
But if I use the FunctionUtilities, I would find calling `boost::function_utilities::pipable` or `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long. I think HigherOrderFunctions is much more descriptive, and then I could use the namespace `hof` for short. Also, the word 'utility' is not very descriptive, and I would prefer to move away from using it. Boost.Utility contains random things in it that are unrelated, and I don't want this library to be described as a collection of random and unrelated functions.
On 9/18/17 7:45 AM, paul via Boost wrote:
If I may suggest a name: I like description on github "function utility library". So what about "Function Utilities", which is quite descriptive. On the Boost library page it would be inserted next to "Function" and "Function Types", which - ironically - seems quite "fit"ting.
But if I use the FunctionUtilities, I would find calling `boost::function_utilities::pipable` or `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long.
at least as far as the namespace is concerned, users can and often do declare namespace alias. Users could also use a forwarding define - eg #define BFU_STATIC_FUNCTION BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION So if the length of names is a concern it is addressable. Perhaps a small section in the docs might suggest this. There's no issue with name collision as it's it totally in the hands of the user who might want to make his own code more readable. Speaking of docs - a section FAQ might be a good place for all the miscellaneous questions which arise in the review and subsequent complaints. If you keep updating this, you'll find that you get no more questions eventually. FunctionUtilities. This seems to overlap with boost.callable library. here are ones that occurred to me UnifiedFunctionCalling UnifiedFunctionInteraces FunctionInterfaces Naming is always an issue and never satisfies everyone. Just do your best. Robert Ramey
I think HigherOrderFunctions is much more descriptive, and then I could use the namespace `hof` for short.
Also, the word 'utility' is not very descriptive, and I would prefer to move away from using it. Boost.Utility contains random things in it that are unrelated, and I don't want this library to be described as a collection of random and unrelated functions.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 18. Sep 2017, at 16:45, paul <pfultz2@yahoo.com> wrote:
But if I use the FunctionUtilities, I would find calling `boost::function_utilities::pipable` or `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long.
I think HigherOrderFunctions is much more descriptive, and then I could use the namespace `hof` for short.
I hope I am not bike-shedding here. I do believe that names are important, because they are the first thing you see of a library, and I believe that "obviousness" is an important factor. I can see where you are coming from, but let me try to defend the name "Function Utilities" a bit, because although I think that using another abbreviation like "hof" is better than "fit", "hof" still leaves me without a clue at first sight. You argue against long macro names and long namespaces, but in my coding experience, people use short aliases for boost namespaces in any case, e.g. `namespace bfu = namespace boost::function_utilities;`. Even for `boost::fit` or `boost::hof`, I believe that people will make an alias, because of the repetitive `boost::` prefix. So the length of the namespace name is not an important factor IMHO. Also, we already have long namespaces in Boost, like boost::program_options, which people happily use. About the macro names, ok, you have a point, BOOST_FUNCTION_UTILITIES_* is longer than BOOST_HOF_*, but if I type it once, my editor is going to auto-complete the long name for me for the rest of the project. There is another general argument in favour of more descriptive names, which I like: "code is written once, but read many times". Therefore, in a tradeoff between readability and writability, it is not bad to lean towards readability. If I was a random guy that reads some code that uses your library, I would scratch my head less at BOOST_FUNCTION_UTILITIES_*.
Also, the word 'utility' is not very descriptive, and I would prefer to move away from using it. Boost.Utility contains random things in it that are unrelated, and I don't want this library to be described as a collection of random and unrelated functions.
I tentatively agree that "Higher Order Functions" is better than "Function Utilities", but yeah it is even longer to write out. Right now we don't have a library with a three word name, this could be the first! The arguments in favor of long names also hold for `boost::higher_order_functions` and BOOST_HIGHER_ORDER_FUNCTIONS_*. Best regards, Hans PS: What if the library was called Boost.HigherOrderFunctions, but the namespace and macros would use boost::hof and BOOST_HOF_*? Would that be an option?
On 9/18/2017 10:45 AM, Hans Dembinski via Boost wrote:
On 18. Sep 2017, at 16:45, paul <pfultz2@yahoo.com> wrote:
But if I use the FunctionUtilities, I would find calling `boost::function_utilities::pipable` or `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long.
I think HigherOrderFunctions is much more descriptive, and then I could use the namespace `hof` for short.
I hope I am not bike-shedding here. I do believe that names are important, because they are the first thing you see of a library, and I believe that "obviousness" is an important factor.
I can see where you are coming from, but let me try to defend the name "Function Utilities" a bit, because although I think that using another abbreviation like "hof" is better than "fit", "hof" still leaves me without a clue at first sight.
You argue against long macro names and long namespaces, but in my coding experience, people use short aliases for boost namespaces in any case, e.g. `namespace bfu = namespace boost::function_utilities;`. Even for `boost::fit` or `boost::hof`, I believe that people will make an alias, because of the repetitive `boost::` prefix. So the length of the namespace name is not an important factor IMHO. Also, we already have long namespaces in Boost, like boost::program_options, which people happily use.
I almost always create an alias to one or more boost::* namespaces. IMHO nearly everyone else too.
About the macro names, ok, you have a point, BOOST_FUNCTION_UTILITIES_* is longer than BOOST_HOF_*, but if I type it once, my editor is going to auto-complete the long name for me for the rest of the project.
There is another general argument in favour of more descriptive names, which I like: "code is written once, but read many times". Therefore, in a tradeoff between readability and writability, it is not bad to lean towards readability. If I was a random guy that reads some code that uses your library, I would scratch my head less at BOOST_FUNCTION_UTILITIES_*.
Also, the word 'utility' is not very descriptive, and I would prefer to move away from using it. Boost.Utility contains random things in it that are unrelated, and I don't want this library to be described as a collection of random and unrelated functions.
I tentatively agree that "Higher Order Functions" is better than "Function Utilities", but yeah it is even longer to write out. Right now we don't have a library with a three word name, this could be the first! The arguments in favor of long names also hold for `boost::higher_order_functions` and BOOST_HIGHER_ORDER_FUNCTIONS_*.
Best regards, Hans
PS: What if the library was called Boost.HigherOrderFunctions, but the namespace and macros would use boost::hof and BOOST_HOF_*? Would that be an option?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 2017-09-18 at 17:45 +0200, Hans Dembinski wrote:
On 18. Sep 2017, at 16:45, paul <pfultz2@yahoo.com> wrote:
But if I use the FunctionUtilities, I would find calling `boost::function_utilities::pipable` or `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long.
I think HigherOrderFunctions is much more descriptive, and then I could use the namespace `hof` for short. I hope I am not bike-shedding here. I do believe that names are important, because they are the first thing you see of a library, and I believe that "obviousness" is an important factor.
I can see where you are coming from, but let me try to defend the name "Function Utilities" a bit, because although I think that using another abbreviation like "hof" is better than "fit", "hof" still leaves me without a clue at first sight.
You argue against long macro names and long namespaces, but in my coding experience, people use short aliases for boost namespaces in any case, e.g. `namespace bfu = namespace boost::function_utilities;`. Even for `boost::fit` or `boost::hof`, I believe that people will make an alias, because of the repetitive `boost::` prefix. So the length of the namespace name is not an important factor IMHO. Also, we already have long namespaces in Boost, like boost::program_options, which people happily use.
About the macro names, ok, you have a point, BOOST_FUNCTION_UTILITIES_* is longer than BOOST_HOF_*, but if I type it once, my editor is going to auto- complete the long name for me for the rest of the project.
There is another general argument in favour of more descriptive names, which I like: "code is written once, but read many times". Therefore, in a tradeoff between readability and writability, it is not bad to lean towards readability. If I was a random guy that reads some code that uses your library, I would scratch my head less at BOOST_FUNCTION_UTILITIES_*.
Also, the word 'utility' is not very descriptive, and I would prefer to move away from using it. Boost.Utility contains random things in it that are unrelated, and I don't want this library to be described as a collection of random and unrelated functions. I tentatively agree that "Higher Order Functions" is better than "Function Utilities", but yeah it is even longer to write out. Right now we don't have a library with a three word name, this could be the first! The arguments in favor of long names also hold for `boost::higher_order_functions` and BOOST_HIGHER_ORDER_FUNCTIONS_*.
Best regards, Hans
PS: What if the library was called Boost.HigherOrderFunctions, but the namespace and macros would use boost::hof and BOOST_HOF_*? Would that be an option?
Yea, thats what I am considering. .
On 9/8/2017 7:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
I have some questions about Fit which I can not understand by reading the docs: 1) Does Fit functionality work only with function objects as opposed to callables in general ? 2) Is the purpose of BOOST_FIT_STATIC_FUNCTION only to create a function object at global or namespace level ? 3) Does BOOST_FIT_STATIC_FUNCTION only accept a function object or does it accept any callable ? 4) The documentation says that "BOOST_FIT_STATIC_LAMBDA_FUNCTION can be used to the declare the lambda as a function". I am not sure what this actually means since a lambda function is a function. 5) I do not understand the purpose of the pipable adaptor. What is the point of using it ? It is mentioned as an alternative to Unified Call Syntax but, while I understand the latter, I do not understandable how pipable allows "extension methods", which is a large part of the purpose of UFCS. In general I am confused by what the requirements of Fit adaptors are. This may be because the terms "function objects" and "functions" are used in a way which does not follow standard C++ terminology as far as I know it. I think I complained about this confusion in my comments regarding Fit in the earlier review, but while the docs seem more extensive than earlier, my confusion still remains.
Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote.
This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php
In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed.
The following is a brief description of the library from its author:
====================
Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming.
Fit is:
Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface.
Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more.
Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components:
Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions.
Requirements
This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.
Contexpr support:
Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs.
Noexcept support:
On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this.
====================
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
Some other questions you might want to consider answering:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed?
More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html
Thank you for participating!
On Sep 15, 2017, at 8:46 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 9/8/2017 7:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost <https://github.com/pfultz2/Fit/tree/boost> Docs: http://pfultz2.github.io/Fit/doc/html/doc/ <http://pfultz2.github.io/Fit/doc/html/doc/>
I have some questions about Fit which I can not understand by reading the docs:
1) Does Fit functionality work only with function objects as opposed to callables in general ?
In general yes, but its not the case for every adaptor.
2) Is the purpose of BOOST_FIT_STATIC_FUNCTION only to create a function object at global or namespace level ?
Yes.
3) Does BOOST_FIT_STATIC_FUNCTION only accept a function object or does it accept any callable ?
It only works with function objects, which I should document its type requirements.
4) The documentation says that "BOOST_FIT_STATIC_LAMBDA_FUNCTION can be used to the declare the lambda as a function". I am not sure what this actually means since a lambda function is a function.
Maybe that could be worded better, but it lets you declare the lambda at global or namespace scope.
5) I do not understand the purpose of the pipable adaptor. What is the point of using it ? It is mentioned as an alternative to Unified Call Syntax but, while I understand the latter, I do not understandable how pipable allows "extension methods", which is a large part of the purpose of UFCS.
That is, you want to add an extension method to a class so it can be called as `x.f(y)`. With UFCS, you can just declare a free function called as `f(x, y)` and then call it as `x.f(y)`, with the Fit library you would declare the function as pipable and then call it as `x | f(y)`.
In general I am confused by what the requirements of Fit adaptors are.
Which ones?
This may be because the terms "function objects" and "functions" are used in a way which does not follow standard C++ terminology as far as I know it.
The type requirements for the adaptors are documented as either `ConstCallable` or `ConstFunctionObject`, which follows standard C++ definitions with an additional `const` requirement.
On 9/16/2017 2:14 PM, P F via Boost wrote:
On Sep 15, 2017, at 8:46 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 9/8/2017 7:02 AM, Matt Calabrese via Boost wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost <https://github.com/pfultz2/Fit/tree/boost> Docs: http://pfultz2.github.io/Fit/doc/html/doc/ <http://pfultz2.github.io/Fit/doc/html/doc/>
I have some questions about Fit which I can not understand by reading the docs:
1) Does Fit functionality work only with function objects as opposed to callables in general ?
In general yes, but its not the case for every adaptor.
OK.
2) Is the purpose of BOOST_FIT_STATIC_FUNCTION only to create a function object at global or namespace level ?
Yes.
OK.
3) Does BOOST_FIT_STATIC_FUNCTION only accept a function object or does it accept any callable ?
It only works with function objects, which I should document its type requirements.
Please do.
4) The documentation says that "BOOST_FIT_STATIC_LAMBDA_FUNCTION can be used to the declare the lambda as a function". I am not sure what this actually means since a lambda function is a function.
Maybe that could be worded better, but it lets you declare the lambda at global or namespace scope.
OK.
5) I do not understand the purpose of the pipable adaptor. What is the point of using it ? It is mentioned as an alternative to Unified Call Syntax but, while I understand the latter, I do not understandable how pipable allows "extension methods", which is a large part of the purpose of UFCS.
That is, you want to add an extension method to a class so it can be called as `x.f(y)`. With UFCS, you can just declare a free function called as `f(x, y)` and then call it as `x.f(y)`, with the Fit library you would declare the function as pipable and then call it as `x | f(y)`.
Let us suppose I have a class: struct X { some member functions etc. }; Then I want to add a member function to class X with a prototype called void f(int) so I can call it as an extension method without modifying X. With UFCS in effect I create the free function: void f(X px,int py) { some implementation } and now if I have: X x; I can call: x.f(3); // Works with UFCS support successfully. Could you please show me the equivalent code that uses pipable in this same scenario ?
In general I am confused by what the requirements of Fit adaptors are.
Which ones?
This may be because the terms "function objects" and "functions" are used in a way which does not follow standard C++ terminology as far as I know it.
The type requirements for the adaptors are documented as either `ConstCallable` or `ConstFunctionObject`, which follows standard C++ definitions with an additional `const` requirement.
OK. Thanks !
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sep 16, 2017, at 2:31 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 9/16/2017 2:14 PM, P F via Boost wrote:
5) I do not understand the purpose of the pipable adaptor. What is the point of using it ? It is mentioned as an alternative to Unified Call Syntax but, while I understand the latter, I do not understandable how pipable allows "extension methods", which is a large part of the purpose of UFCS. That is, you want to add an extension method to a class so it can be called as `x.f(y)`. With UFCS, you can just declare a free function called as `f(x, y)` and then call it as `x.f(y)`, with the Fit library you would declare the function as pipable and then call it as `x | f(y)`.
Let us suppose I have a class:
struct X { some member functions etc. };
Then I want to add a member function to class X with a prototype called void f(int) so I can call it as an extension method without modifying X. With UFCS in effect I create the free function:
void f(X px,int py) { some implementation }
and now if I have:
X x;
I can call:
x.f(3); // Works with UFCS support
successfully. Could you please show me the equivalent code that uses pipable in this same scenario ?
You could define `f` like this(using a lambda for simplification): BOOST_FIT_STATIC_LAMBDA_FUNCTION(f) = boost::fit::pipable([](X px,int py) { some implementation }); And then you can call it like this: X x; x | f(3); // Calls f as f(x, 3)
On 9/16/2017 7:53 PM, P F via Boost wrote:
On Sep 16, 2017, at 2:31 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 9/16/2017 2:14 PM, P F via Boost wrote:
5) I do not understand the purpose of the pipable adaptor. What is the point of using it ? It is mentioned as an alternative to Unified Call Syntax but, while I understand the latter, I do not understandable how pipable allows "extension methods", which is a large part of the purpose of UFCS. That is, you want to add an extension method to a class so it can be called as `x.f(y)`. With UFCS, you can just declare a free function called as `f(x, y)` and then call it as `x.f(y)`, with the Fit library you would declare the function as pipable and then call it as `x | f(y)`.
Let us suppose I have a class:
struct X { some member functions etc. };
Then I want to add a member function to class X with a prototype called void f(int) so I can call it as an extension method without modifying X. With UFCS in effect I create the free function:
void f(X px,int py) { some implementation }
and now if I have:
X x;
I can call:
x.f(3); // Works with UFCS support
successfully. Could you please show me the equivalent code that uses pipable in this same scenario ?
You could define `f` like this(using a lambda for simplification):
BOOST_FIT_STATIC_LAMBDA_FUNCTION(f) = boost::fit::pipable([](X px,int py) { some implementation });
And then you can call it like this:
X x; x | f(3); // Calls f as f(x, 3)
OK. Thanks ! BTW I do not recall seeing anywhere in the doc where you mention that Fit constructs are in the boost::fit namespace.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
A couple of questions: 1) It seems to be that this library only applies to function objects. Is this impression correct? I get this impression from the "getting started" and other material and I'm fine with this. But when I go to the reference for is_callable I find: "The is_callable metafunction checks if the function is callable with certain parameters." which seems to suggest that this meta function would work as expected when passed a pointer to a function. If it's to apply only to function objects, I would expect the above to read: "The is_callable metafunction checks if the function object is callable with certain parameters." 2) I wonder about some names. In some cases it seems that the library provides some C++17 functionality under a different name: is_callable ?-> std::is_invocable http://en.cppreference.com/w/cpp/utility/functional/invoke apply ?-> std::invoke http://en.cppreference.com/w/cpp/utility/functional/invoke
On Sep 17, 2017, at 5:13 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
A couple of questions:
1)
It seems to be that this library only applies to function objects. Is this impression correct?
No.
I get this impression from the "getting started" and other material and I'm fine with this.
The “getting started” uses function objects because they are more powerful, but only a few adaptors are limited to a function object. Each adaptor is documented whether it takes a function object or a “Callable”.
But when I go to the reference for is_callable I find:
"The is_callable metafunction checks if the function is callable with certain parameters."
which seems to suggest that this meta function would work as expected when passed a pointer to a function. If it's to apply only to function objects, I would expect the above to read:
"The is_callable metafunction checks if the function object is callable with certain parameters.”
The documentation for `is_callable` states that "F must be Callable”, with a link to the “Callable” definition.
2)
I wonder about some names. In some cases it seems that the library provides some C++17 functionality under a different name:
is_callable ?-> std::is_invocable http://en.cppreference.com/w/cpp/utility/functional/invoke
apply ?-> std::invoke http://en.cppreference.com/w/cpp/utility/functional/invoke <http://en.cppreference.com/w/cpp/utility/functional/invoke>
Yes, those need to be renamed as Vicente pointed out as well. I have an issue for this rename here: https://github.com/pfultz2/Fit/issues/171
On 9/8/17 4:02 AM, Matt Calabrese via Boost wrote:
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including > Fit as a Boost library. Please be explicit about your decision.
I recommend that the review manager accept this library into boost without conditions.
Some other questions you might want to consider answering:
- What is your evaluation of the designGood - - What is your evaluation of the implementation? I didn't look into it. - What is your evaluation of the documentation? Much better than average. Basically quite usable. The Getting Started was very helpful to me. - What is your evaluation of the potential usefulness of the library? It took me a while to see this, but I realize that I could see this right now. - Did you try to use the library? With which compiler(s)? Did you have any problems? I didn't try it - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Two hours of poking through the documentation in the context of some current issues I'm dealing with. - Are you knowledgeable about the problem domain? Compared to whom? Actually I don't consider myself particularly knowledgeable. I did spend a fair amount of time looking at boost.functional, boost.call_traits and cpp_reference functional, and some C++17 constructs like is_invocable, etc. After I did all that the purpose, utility and usage seemed pretty straight forward. - Were the concerns from the March 2016 review of Fit addressed? I didn't do a review in March 2016.
Robert Ramey
On Sep 17, 2017, at 6:21 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 9/8/17 4:02 AM, Matt Calabrese via Boost wrote:
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including > Fit as a Boost library. Please be explicit about your decision.
I recommend that the review manager accept this library into boost without conditions.
Some other questions you might want to consider answering: - What is your evaluation of the designGood - - What is your evaluation of the implementation? I didn't look into it. - What is your evaluation of the documentation? Much better than average. Basically quite usable. The Getting Started was very helpful to me. - What is your evaluation of the potential usefulness of the library? It took me a while to see this, but I realize that I could see this right now. - Did you try to use the library? With which compiler(s)? Did you have any problems? I didn't try it - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Two hours of poking through the documentation in the context of some current issues I'm dealing with. - Are you knowledgeable about the problem domain? Compared to whom? Actually I don't consider myself particularly knowledgeable. I did spend a fair amount of time looking at boost.functional, boost.call_traits and cpp_reference functional, and some C++17 constructs like is_invocable, etc. After I did all that the purpose, utility and usage seemed pretty straight forward. - Were the concerns from the March 2016 review of Fit addressed? I didn't do a review in March 2016.
Thanks for the review.
On Fri, Sep 8, 2017 at 6:02 AM, Matt Calabrese via Boost < boost@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. (snip)
I recommend to ACCEPT the Fit library into Boost unconditionally.
- What is your evaluation of the design?
I like it.
- What is your evaluation of the implementation?
Have not reviewed in recent times. I'm very impressed with the claimed compiler support, although I'm curious to know how Clang 4 and Clang 5 fare. I realize the importance of an implementation review for this library, so I trust that Matt will weigh this lightweight review appropriately.
- What is your evaluation of the documentation?
Good. I would like to see pound-include lines added to all of the early examples. So many times as a user of Boost I have had to cross reference example code with the reference docs just to find the include path, which is annoying.
- What is your evaluation of the potential usefulness of the library?
Very useful! I would have used this a handful of times at work already, had it been available in Boost.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
No, at least not recently.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Tonight, about an hour reading documentation. Cumulatively, several hours over the past couple of years. I have been following Fit since before the 2016 review, so I'm thrilled to see it up for review again.
- Are you knowledgeable about the problem domain?
Yes, although my experience with functional programming is mostly limited to TMP.
- Were the concerns from the March 2016 review of Fit addressed?
N/A Barrett Adair
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Barrett Adair via Boost [boost@lists.boost.org] Sent: 20 September 2017 05:26 To: boost@lists.boost.org Cc: Barrett Adair Subject: Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
Have not reviewed in recent times. I'm very impressed with the claimed compiler support, although I'm curious to know how Clang 4 and Clang 5 fare.
I have some examples which cover almost all of the library. These compile fine with Clang 4.0.0 (C++14 and C++1z) and Clang 5.0.0 (C++14 and C++17). The examples also compile fine with gcc 6.4 (C++14 and C++17) and gcc 7.1(C++14 and C++17) This is on Ubuntu Linux. I hope this helps. John Fletcher
On Tue, 2017-09-19 at 23:26 -0500, Barrett Adair via Boost wrote:
On Fri, Sep 8, 2017 at 6:02 AM, Matt Calabrese via Boost < boost@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. (snip)
I recommend to ACCEPT the Fit library into Boost unconditionally.
Thanks you for the review.
- What is your evaluation of the design?
I like it.
- What is your evaluation of the implementation?
Have not reviewed in recent times. I'm very impressed with the claimed compiler support, although I'm curious to know how Clang 4 and Clang 5 fare.
I have tested on newer clang versions, but I don't have them in my travis CI to regularly test. There always seemed to be an issue using LLVM's apt repo.
I realize the importance of an implementation review for this library, so I trust that Matt will weigh this lightweight review appropriately.
- What is your evaluation of the documentation?
Good. I would like to see pound-include lines added to all of the early examples. So many times as a user of Boost I have had to cross reference example code with the reference docs just to find the include path, which is annoying.
- What is your evaluation of the potential usefulness of the library?
Very useful! I would have used this a handful of times at work already, had it been available in Boost.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
No, at least not recently.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Tonight, about an hour reading documentation. Cumulatively, several hours over the past couple of years. I have been following Fit since before the 2016 review, so I'm thrilled to see it up for review again.
- Are you knowledgeable about the problem domain?
Yes, although my experience with functional programming is mostly limited to TMP.
- Were the concerns from the March 2016 review of Fit addressed?
N/A
Barrett Adair
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo st
On Fri, Sep 8, 2017 at 7:02 AM, Matt Calabrese <rivorus@gmail.com> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today
After the extension to September 20th, this review period has come to a close. Thanks to everyone who participated. I will do my best to post review results before this coming Monday. For anyone who participated but did not explicitly state whether they wish to accept or reject, you can still do so now if you wish, otherwise I will weigh the discussions to the best of my ability. If anyone has something further to add, do not be hesitant to post and I will try to incorporate your thoughts, though do try to meet the deadline on future boost reviews. Thanks again to everyone. -- -Matt Calabrese
I accidentally sent this to boost-announce where it is blocked in moderation - resending to the main list. On Fri, 8 Sep 2017 07:02:27 -0400 Matt Calabrese via Boost via Boost-announce <boost-announce@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
[...]
Requirements
This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.
Contexpr support:
Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs.
`FIT_LIFT` uses `auto` in a C++14-style lambda, and thus does not compile when in C++11 mode.
Noexcept support:
On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this.
====================
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I would vote to accept the library.
Some other questions you might want to consider answering:
- What is your evaluation of the design?
Overall I have a positive impression of the design. In general there is a logical consistency to the adaptors / decorators. The `infix` operator still feels like a gimmick - why include it in the library? I cannot think of an instance where I would use such a utility, especially considering the fragility of operator precedence.
- What is your evaluation of the implementation?
I think there are too many macros internally, but I think its mostly to work around compilers. So its about average for a boost library. I also do not like the inheritance from user-callables, as it seems unnecessary in some cases (although perhaps easiest for `match`, etc.?).
- What is your evaluation of the documentation?
The documentation seems to be improved from what I remember. At first I felt like the getting started and examples section was "too much too fast", but I am not sure there is an easy way to introduce a programmer to some of these concepts. Is the library inspired by another, or entirely by "point-free programming"? I am trying to think of some outside resource to reference, but I cannot think of any.
- What is your evaluation of the potential usefulness of the library?
Some of the utilities will be valuable for C++11 projects (move capture), and I also like the "pack" handling functions that will not be available until C++17. A number of the adaptors seem like they could be useful, but I've also not written anything similar or considered doing so. Which might mean I need to do more functional programming.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
This time I just used the `BOOST_LIFT` function, tried out the auto-placeholder and pipable adaptor to study their behavior.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I spent significantly more the first review, particularly with the implementation. I spent only a 1-2 hours looking at the code / documentation this time.
- Are you knowledgeable about the problem domain?
This is a fairly unique project; I do not know specifics about this type of point-free or functional programming. I am fairly familiar with std/boost bind and the usage of basic callables.
- Were the concerns from the March 2016 review of Fit addressed?
I brought up inheritance from user types as a potential issue. The author disagreed? A small implementation quirk, but can lead to surprising behavior with operator overloads, etc. I also suggested (i.e. not a concern necessarily) that the placeholders be placed into their own namespace. This would allow `using boost::fit::placeholders` without bringing the entire `boost::fit` namespace into scope. The library could still alias the placeholders into the `boost::fit` namespace as well. There is also this strange oddity: struct { int operator()(int x, int y = 10) const noexcept { return x + y; } } sum{}; const auto pipe_sum = boost::fit::pipable(sum); int main() { std::cout << (1 | pipe_sum) << std::endl; return 0; } The function is immediately evaluated, without `()` on pipe_sum and outputs `11`. I looked through my post last time, and recommended that something in the documentation mention that `pipable` behaves like a `partial` evaluation. Or again, maybe that's obvious from the pack listed in the documentation? So while the partial evaluation might be obvious due to the documentation, the immediate evaluation without the extra `()` is still intriguing.
More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html
Thank you for participating!
Lee
On Thu, 2017-09-21 at 11:39 -0400, Lee Clagett via Boost wrote:
I accidentally sent this to boost-announce where it is blocked in moderation - resending to the main list.
On Fri, 8 Sep 2017 07:02:27 -0400 Matt Calabrese via Boost via Boost-announce <boost-announce@lists.boost.org> wrote:
A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17.
A branch has been made for the review. You can find Fit for review at these links:
Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/
[...]
Requirements
This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported.
Contexpr support:
Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs.
`FIT_LIFT` uses `auto` in a C++14-style lambda, and thus does not compile when in C++11 mode.
Yes, but `FIT_LIFT_CLASS` does work in C++11. I will add a note about that.
Noexcept support:
On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this.
====================
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I would vote to accept the library.
Thanks for the review.
Some other questions you might want to consider answering:
- What is your evaluation of the design?
Overall I have a positive impression of the design. In general there is a logical consistency to the adaptors / decorators.
The `infix` operator still feels like a gimmick - why include it in the library? I cannot think of an instance where I would use such a utility, especially considering the fragility of operator precedence.
A lot of people think its useful. To me it seems to be useful over pipable at removing parenthesis in the function call. So an infix `mfor`(ie the monadic bind operator) could be used like this: auto triples = view::iota(1) <mfor> [](int z) { return ints(1, z) <mfor> [=](int x) { return ints(x, z) <mfor> [=](int y) { return yield_if(x*x + y*y == z*z, std::make_tuple(x, y, z)); }; }; }; Or if we get `=>` for transparent returns, theres even less balancing of braces: auto triples = view::iota(1) <mfor> [](int z) => ints(1, z) <mfor> [=](int x) => ints(x, z) <mfor> [=](int y) => yield_if(x*x + y*y == z*z, std::make_tuple(x, y, z)); Of course, builtin support for monadic comprehension in C++ would be better, but this is probably the best you can do without resorting to macros.
- What is your evaluation of the implementation?
I think there are too many macros internally, but I think its mostly to work around compilers. So its about average for a boost library.
Well macros are used to help improve compatibility, and improve compile-time performance where possible(ie using intrinsics over type traits).
I also do not like the inheritance from user-callables, as it seems unnecessary in some cases (although perhaps easiest for `match`, etc.?).
Of course, if a function is not meant to inherit, it should be declared with `final`, but if thats not enough, you can use `capture(f)(apply)` to prevent inheritance.
- What is your evaluation of the documentation?
The documentation seems to be improved from what I remember. At first I felt like the getting started and examples section was "too much too fast", but I am not sure there is an easy way to introduce a programmer to some of these concepts. Is the library inspired by another, or entirely by "point-free programming"? I am trying to think of some outside resource to reference, but I cannot think of any.
It heavily-inspired by the Boost.Egg library: http://p-stade.sourceforge.net/boost/libs/egg/doc/html/index.html Which there is a link to in the 'Acknowledgements' section.
- What is your evaluation of the potential usefulness of the library?
Some of the utilities will be valuable for C++11 projects (move capture), and I also like the "pack" handling functions that will not be available until C++17.
Are you referring to structured bindings?
A number of the adaptors seem like they could be useful, but I've also not written anything similar or considered doing so. Which might mean I need to do more functional programming.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
This time I just used the `BOOST_LIFT` function, tried out the auto-placeholder and pipable adaptor to study their behavior.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I spent significantly more the first review, particularly with the implementation. I spent only a 1-2 hours looking at the code / documentation this time.
- Are you knowledgeable about the problem domain?
This is a fairly unique project; I do not know specifics about this type of point-free or functional programming. I am fairly familiar with std/boost bind and the usage of basic callables.
- Were the concerns from the March 2016 review of Fit addressed?
I brought up inheritance from user types as a potential issue. The author disagreed? A small implementation quirk, but can lead to surprising behavior with operator overloads, etc.
I also suggested (i.e. not a concern necessarily) that the placeholders be placed into their own namespace. This would allow `using boost::fit::placeholders` without bringing the entire `boost::fit` namespace into scope. The library could still alias the placeholders into the `boost::fit` namespace as well.
That is a good idea. I will do that.
There is also this strange oddity:
struct { int operator()(int x, int y = 10) const noexcept { return x + y; } } sum{}; const auto pipe_sum = boost::fit::pipable(sum);
int main() { std::cout << (1 | pipe_sum) << std::endl; return 0; }
The function is immediately evaluated, without `()` on pipe_sum and outputs `11`. I looked through my post last time, and recommended that something in the documentation mention that `pipable` behaves like a `partial` evaluation.
There is a discussion about partial evaluation and its pitfall, here: http://pfultz2.github.io/Fit/doc/html/doc/src/partialfunctions.html I do mention that pipable is one of the adaptors that uses partial evaluation, but I probably should mention it on the pipable reference page.
Or again, maybe that's obvious from the pack listed in the documentation? So while the partial evaluation might be obvious due to the documentation, the immediate evaluation without the extra `()` is still intriguing.
I don't mention that. This probably should be mentioned and added to the semantics section. Paul .
On 9/21/17 12:23 PM, paul via Boost wrote:
- What is your evaluation of the implementation? I think there are too many macros internally, but I think its mostly to work around compilers. So its about average for a boost library.
Well macros are used to help improve compatibility, and improve compile-time performance where possible(ie using intrinsics over type traits).
Hmmm - I didn't catch this. I had presumed that macros were used because there was no other way to implement the required functionality. I don't think that saving a little bit of compile time is a good justification for defining a macro. Robert Ramey
On Thu, 2017-09-21 at 13:10 -0700, Robert Ramey via Boost wrote:
On 9/21/17 12:23 PM, paul via Boost wrote:
- What is your evaluation of the implementation?
I think there are too many macros internally, but I think its mostly to work around compilers. So its about average for a boost library.
Well macros are used to help improve compatibility, and improve compile- time performance where possible(ie using intrinsics over type traits).
Hmmm - I didn't catch this. I had presumed that macros were used because there was no other way to implement the required functionality. I don't think that saving a little bit of compile time is a good justification for defining a macro.
Its about 50-60% faster on clang. Hana uses similar intrinsics where possible. Ideally, it would be nice to have these in a separate library, so these macros can be easily used in more libraries. .
I apologize for submitting my review late. For some reason, I thought the extension was until the 22nd.
Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision.
I vote to ACCEPT Fit unconditionally.
Some other questions you might want to consider answering:
- What is your evaluation of the design?
Good, just like in the first review.
- What is your evaluation of the implementation?
Good. The implementation can sometimes be obscure because of support for older compilers, but it's probably worth it.
- What is your evaluation of the documentation?
Really great. In fact, I think Paul's system for documentation with readthedocs.io and markdown slurped from his source files is awesome, and I'm looking forward to using it in some of my projects.
- What is your evaluation of the potential usefulness of the library?
I think it's only useful in a handful of cases (the rest of the time you can usually use lambdas). However, when you need it, you really don't want to reimplement it yourself, so it has its utility.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
Haven't tried since the last review.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I had put significant effort in my initial review, but did not have time to do much besides skim the documentation and the issue list this time around.
- Are you knowledgeable about the problem domain?
Very; Hana has a 'Functional' module that implements many, but not all, of the things in Fit. I was looking forward to Fit being accepted in Boost so I could consider dropping support for this part of Hana, which does not really belong to Hana.
- Were the concerns from the March 2016 review of Fit addressed?
Hard to tell because no official report was given for the first review, but it seems like pretty much all the issues that I cared about have been taken care of, since the associated GitHub issues have been closed: https://github.com/pfultz2/Fit/issues?q=is%3Aissue+author%3Aldionne+is%3Aclo... This is mostly what my vote is based on; I had only a few reservations about this library the first time around, and they have now been resolved. Thanks Paul for this nice library, and to Matt for managing the review. Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
participants (13)
-
Barrett Adair -
Edward Diener -
Fletcher, John P -
Hans Dembinski -
Lee Clagett -
Louis Dionne -
Matt Calabrese -
P F -
paul
-
Robert -
Robert Ramey -
Vicente J. Botet Escriba -
Zach Laine