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.
Well, you already on planning to move to use Fit, instead of whats currently in the Functional part. Also, the way you define concepts are very interesting and might be a good library on its own as other libraries that don't need metaprogramming may want use it. Of course, its best to see what happens as the library grows. I believe something similar happened to Spirit. It was one library and then split out to other libraries(such as Phoenix and Fusion).
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:
Well the Fit library provides a lot of this core capability, I believe. It has a focus on being lightweight instead providing something highly generic.
- An efficient tuple implementation (std::tuple usually sucks, sorry)
The Fit library already provides an efficient tuple implementation. Additionally, it is also empty optimized on compilers that support it(current only clang does). However, with the goal of being lightweight, it doesn't provide indexed accessors directly. They could be implemented easily using `args`, however, for more sophisticated needs like that, Hana should just be used instead.
- Efficient algorithms on this tuple type
Yes, and the Fit library provides the components to easily do algorithms on
sequences. `tuple_cat` can be implemented in one line:
auto tuple_cat = unpack(constructstd::tuple());
As well as `for_each`:
auto for_each = [](auto&& seq, auto f) { unpack(by(f))(seq); };
And `transform`:
auto transform = [](auto&& seq, auto f) { return unpack(by(f,
constructstd::tuple()))(seq); };
And `fold`:
auto fold = [](auto&& seq, auto f) { return unpack(compress(f))(seq); };
Plus, its extensible and could be adapted to work with fusion sequences as
well:
template<class Sequence>
struct unpack_sequence
- A way to wrap types into values
I think this is fairly trivial as well. There doesn't seem to be a need for a complete separate library: template<class T> struct type { using type = T; }; template<class T> type<T> decltype_(T&&) { return {}; }
- Extended integral constants with operators
The Tick library also provides extended integral constants with operators. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Re-Hana-Formal-review-tp4677251p4677295.h... Sent from the Boost - Dev mailing list archive at Nabble.com.