Mostafa
On Wed, 30 Jul 2014 13:19:44 -0700, Louis Dionne
wrote: [...]
If you haven't/aren't already doing so, you can explicitly document: 1) That this is an FP library. 2) Why it is so and how this impacts the naming and design. Explicitly, why a non-FP approach would make for a sub-par library. 3) When any unfamiliar (to C++ programmers) names are first introduced provide (the approximate?) C++ mapping.
Hmmm. Yes, it definitely makes sense to at least put a warning sign and to give rationales. That would basically do the job I'm currently doing on this list, but once and for all. Will do.
A part of the documentation may just be about educating a FP-illiterate audience. It would also be help if some of the C++14 concepts were explained, or in the least their use highlighted with appropriate links to references.
I won't write a tutorial on C++14, but I'll put relevant links when I use something that's new in the language. Thanks for the suggestion, I had'nt thought of that.
One last thought, as Joe-everyday programmer why should I care about this library? What does it allow me to do (or do easier) that I wasn't able to do before?
If you either use MPL/Fusion or do any non-trivial std::tuple manipulation, Hana will reduce the complexity of your metaprogramming code by giving you high level abstractions at low compile-time cost. For example, instead of doing like those folks did here http://stackoverflow.com/a/20441189/627587 just to unpack a std::tuple into a variadic function, you would write unpack(f, std::make_tuple(...)) == f(...) with Hana. And it's going to compile just as fast as the hand-written version. If you're willing to use the tuple provided by Hana, it's going to compile much, much faster. If you don't do any kind of metaprogramming, Hana is not for you.