David Sankel
On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes
wrote: [...]
You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design
The core technique of combining value and type expressions is solid and makes metaprogramming easier and, as a bonus, improves compilation speeds.
I'd just like to point out that representing types as value is not what makes compilation faster. It is actually the oposite: representing type-level computations at the type-level is indeed faster, since the compiler has less work to do. What makes Hana faster than Fusion/MPL is the usage of modern C++14 techniques and also a design built around the compiler's execution model rather than the machine's execution model (like the STL/Fusion/MPL with iterators). For pure type-level computations (which are mostly a myth in C++14, because you usually don't need them that much), the fastest way to go would be to use something like the MPL11 I presented in 2014, or Meta (if it's implementation is clever enough). Basically, a MPL (pure-type), but using C++11/14 techniques. However, then you're back to the great fun of writing type-level computations like you did in C++03. My gamble with Hana is that for the very few times you actually need type-level computations, taking a small compile-time hit is worth the expressiveness gain and the ease of interfacing with your actual heterogeneous runtime code (written also with Hana), which is what's important at the end of the day.
My one question, as I read though the implementation, is "can the core benefits of this library be achived with a simpler 'light' version of this implementation?". While I appreciate the attempt to encode a Haskell-style typeclass hierarchy, I feel like that is not the core competency of hana and should be a separate library and discussion. As it is, this is a 32k header mega library. I'd prefer several small, highly-targeted, highly-composable libraries.
Yes, it would be possible. That would mean (non exhaustively): Pros: - No conceptual overhead (it would dumb tuples + algorithms, nothing else) - Slightly faster compile times (smaller library) Cons - No real separation in concepts. This is the flipside of having no conceptual overhead. - No interoperation with other libraries (STL/Fusion/MPL) - No (or very little) possibility of extending the library by users. Don't even try defining your own sequence, it wouldn't be supported. Hana advertises itself as a "standard library for metaprogramming". If you look at Eric's Range library, for example, he also has to define a truckload of concepts to get this done. My feeling is that in order to do something _cleanly_, one must sometimes aim for something larger than the strict minimum that can technically get the job done. That's what I went for. However, it is clear that for some users doing simple stuff Hana's concepts will just be annoying. Hence, there is definitely value in a library that would basically implement Hana's core, but only that. Shooting from the hip, that would include: - An efficient tuple implementation (std::tuple usually sucks, sorry) - Efficient algorithms on this tuple type - A way to wrap types into values - Extended integral constants with operators - Maybe, but just maybe, a compile-time Optional That could either be a different library (I could consider taking this over in the future), or splitting Hana in such a way that this Core content can be accessed without any conceptual/compile-time overhead. However, this is either a non-trivial redesign of the library or a new library completely, so it is part of a "future plan".
* Implementation
The code itself looks to be well structured and well documented.
Unfortunately hana only works with one compiler: clang. While I agree that Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is going too far in the opposite direction. The home page states that boost libraries "are intended to be widely useful, and usable across a broad spectrum of applications". I've always interpreted that statement to be in a practical rather than theoretical sense and I don't think hana meets that criteria. Many other Boost authors have made heroic efforts to meet that criteria and the reputation of Boost is due, in no small part, to those efforts.
I do appreciate the argument that making use of new features encourages compiler implementers to implement then. I maintain, however, that this isn't Boost's job. Boost provides high quality libraries that the every-day Joe C++ developer can benefit from.
That being my position on the issue, my acceptance vote is conditional on hana supporting at least two released versions of mainstream compilers. Given that gcc support seems pretty close, that shouldn't be hard to achieve.
[Be warned, I'm getting slightly emotive below.] It's not about me, it's about them. Seriously, go look at GCC's or Clang's bug trackers. Since I seem to be the only user doing "real" stuff with new C++14 features, I'm also the one finding a lot of the bugs. But of course, I don't weight much in the balance when paying customers(*) ask for bugs to be fixed, or when more obvious C++03 bugs appear. The most important thing stopping Hana from becoming more mature (and higher quality) is the lack of users and the lack of support from compilers. Both can be fixed __very quickly__ by entering Boost, or we could also sit back and enjoy the ride for the next year or so. (*) I waited for this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 to be fixed for more than 2 months. The bug was fixed 2 days after someone I know filed the same bug against RedHat. The dev who fixed the bug worked for RedHat, and the fix was 2 lines of code in GCC. That could be a coincidence, but I doubt it. What I'm asking for is not rock solid perfect C++14 support, but I simply need stuff like this int main() { [](auto x) -> decltype((void)x) { }; } to compile on GCC (try it). Oh and by the way, if I don't find these bugs now, you will find them yourself when you use (even trivial) C++14 features in those compilers. So we're all together in the same boat, except for MSVC users who seem to enjoy swimming along.
* Usefulness
Maybe in a couple years for me. Without VS 2015 support at least, I'm going to be waiting a while.
- Did you attempt to use the library?
Yes. Started working through the getting started examples.
If so: * Which compiler(s)
clang 3.6.1
* What was the experience? Any problems?
Nothing more to add. I filed an issues for all problems encountered and they seemed minor.
For the reference of others, the problems are related to the lack of testing on libstdc++ on Linux. I'm working to fix those errors, and also test on libstdc++ on Travis. Thanks a lot for the review, David. I'll try to get your compilation errors fixed ASAP. Regards, Louis