On 7/29/2014 12:23 PM, Louis Dionne wrote:
Edward Diener
writes: [...]
But I do not understand from your documentation how your library relates to Boost MPL. The Boost MPL library is about manipulating and creating types at compile time, and creating logic paths again at compile time to manipulate types. All of this is encapulated by the MPL's notion of metafunctions to do compile-time programming. But I cannot get from your documentation any of the MPL equivalence of how any of this is done with your library. Is your library meant to duplicate/replace this MPL functionality in some way ? Or is it meant to do something else entirely not related to compile-time programming ?
I had started to reply with a lengthy explanation of how it works, but that would not fix the problem because it is now clear that my documentation _is_ the problem. I'll improve it, make it more explicit and then post back.
I am only asking this because I had been told that your library is at the the least a replacement for MPL compile-time type manipulation functionality using C++11 on up.
It is, and it's also a replacement for Fusion and hence many other metaprogramming utilities. In particular, I'll write a cheatsheet showing how to do everything in the MPL and everything in Fusion with Hana.
Thank you for taking the time to read the documentation (I assume you did) and give me your feedback.
Please consider also that you are using terminology in the present documentation which does not relate to C++ very well, although it may relate to Haskell for all I know. If you rework the documentation please use C++ terminology for things. As an example you referred to Type<T> as an object when in C++ it is a class. You also refer to type classes and data classes but C++ has no specific meaning for either of those terms. Also while it is useful to give syntactical examples you should explain what is occurring in C++ and not in some hypothetical Haskell-like functional programming language which a C++ programmer does not know. In other words no matter how brilliant or clever your library or your constructs are, you need to explain what functionality does what things and not just that some syntax does something but another similar syntax does something else entirely. Because in actual use if a user of your library chooses to use some syntax, without understanding what the underlying functionality actually accomplishes, it is way too easy to do the wrong thing in more complicated scenarios than what your examples provide.