Le 05/06/15 21:18, Glen Fernandes a écrit :
Dear Boost community,
The formal review of Louis Dionne's Hana library starts Monday, 10th June and ends on 24th June.
Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. <snip> We encourage your participation in this review. At a minimum, kindly state: Here is my mini review. I have created some issues on github. My vote is not subject to the result of any of them. - Whether you believe the library should be accepted into Boost Yes, yes and yes. I consider Boost.Hana must be accepted into Boost. - Your name Vicente J. Botet Escriba - Your knowledge of the problem domain. A good knowledge and I have learn a lot more with the work of Louis in Hana.
You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design Brilliant, awesome. Seen types as values is a revolutionary design. Thanks Louis.
I liked the way the Haskel concepts have been adapted to C++14. In previous version of the library (I don't know when this has been changed), I liked * type classes, * the instantiation either directly or when the type is an instance of a type class (using the second parameter). * the minimum definition set and how to inherit from them. * The split concepts and data_types to make it more evident the distinction. All this has now disappeared, surely as requested in this ML :(. Things that I like less are * the data_type (tag) concept. IMO, what is behind is a type constructor. A type constructor is a class that has a nested alias template apply to build new types. A class template can also be seen as a type constructor by lifting it. * the fact that the result type of a lot of functions is not a concrete type or is not defined. * the fact that the interface is not typed, the use of auto and lambdas everywhere is less informative that a typed interface. * the Signature as an alternative way to define the interface should be documented. I would find more useful to define the signature before the description. * This is a library with a lot of Concepts. It is not easy to find the correct name for each of them and each of the functions in the C++ world when the concepts come from another language with different history. There are some names that I don't like, but I recognize that finding a coherent set of names is not easy. * the fact that all the functions are in the same namespace. This imply that we need to find a different name for each function. Making use of namespaces for each concept add a freedom degree. * The functional part has disappeared as there were some overlapping with Boost.Fit (We need now Boost.Fit). * the instantiation either directly or when the type is an instance of a type class (using the second parameter). I'm not yet clear about * the fact that Hana has reimplemented part of the standard to avoid dependencies and improve performances. IMHO, this is not the C++ way, but Maybe the C++ standard library should be structured in a different way. Maybe the expected modules could help here.
* Implementation I used to inspect the old version. I have less inspected the current one.
I find it quite clear and elegant even if I prefer the architecture of the old version.
* Documentation
Very good tutorial. The documentation would improve a lot with a better design rationale section. * What a Concept is and how the map is done. * What a Tag/datatype is, why do we need it, alternatives, and how all this works. * Naming and order of parameters * Why and when free functions or member functions are used. The reference documentation is a little bit confusing for some one used to the C++ standard way. * The terms Concept/Superclass/Methods, ... * The Signature as an alternative way to define the interface should be documented. I would find more useful to define the signature before the description. * A more formal definition of the mappings from concrete type to Concepts and the Super classes Maybe this is enough for Boost, but I would like to see a more C++ standard like documentation.
* Tests Not inspected in depth, but it seems well covered. * Usefulness Very useful.
Even if I have not used it directly, I have taken a lot of ideas from his design. If the announced performances are there, it is clear that Boost.Hana will be used more a more by those that can use a C++14 compiler. I'll hope adding a dependency on the C++ standard library will not degrade the performance so much.
- Did you attempt to use the library? If so: No yet.
I will do it as soon as I install the good compiler version.
* Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review?
Thanks again Louis for this wonderful library. I would like to see in Boost a similar functional library but this time for run-time types. Vicente