Hana was designed as a replacement for both the MPL and Fusion. Technically, everything you can express with the MPL can be expressed with Hana; I'm working on a mathematical proof for it. The question really is whether it is _convenient_ to do so, and my current opinion is yes. However, metaprogramming with Hana requires you to stop thinking in a MPL way, i.e. with traditional metafunctions. If you keep your old MPL habits, you will end up having to decltype function call expressions all the time, which I agree is cumbersome. If you embrace this new way of metaprogramming, you will only have to use decltype at some precise boundaries; when you actually _need_ a type at the end of the whole computation. My assumption in designing Hana was that while all of our current type-level computations are implemented at the type-level, this is just a side effect of using the MPL and we actually need the types only at some thin boundaries.
Exactly, the question is all about convenience.
I suspect (1) the lack of guidelines for doing type-level metaprogramming in Hana (2) the lack of a serious case study (e.g. implementing Phoenix with Hana) could be why people don't see Hana as being fit for a MPL replacement; they don't see how we can achieve type-level metaprogramming easily, which is legitimate given (1) and (2).
I clarified the tutorial[1] to improve the situation of (1), but there is still room for improvement. As for (2), I guess I am the one who should take the lead; if someone has a suggestion for a good guinea pig, please let me know. Otherwise, I started implementing the core of Accumulators with Hana; we'll see how that goes.
I too believe that once people start seeing some nice examples comparing both approaches, and if Hana does present a neater syntax, then people will become less resistant to switching. Since Hana takes advantage of the newest additions to the C++, it should indeed be more concise than MPL, I believe. Btw, the tutorial is indeed much clearer now, thank you for improving it.
FWIW, I am personally not in favor of having two metaprogramming libraries living side by side. This causes code duplication and interoperation issues, and it also increases the learning curve. Also, you won't be able to backport MPL11 to MPL because I diverged from the MPL in a rather major way by using lazy metafunctions in MPL11. They are more composable and you also don't have to write "typename" everywhere, but it breaks backward compatibility pretty severely.
That's where our opinions diverge a bit. Could Hana be compiled anywhere MPL is, than sure, why not just switch onto something with a neater syntax? It would be a natural process for developers to start porting their codes. However, I'm afraid that's not the case, in fact it could never be, for by simply depending on C++14, it denies support to a whole bunch of platforms and will still for many, many years. In my opinion one of the greatest feats of Boost is the fact its libraries mostly support a very wide range of setups and it is no wonder why so many Boost libraries make use of MPL for that matter. The way I foresee it, applications will be using Hana, while libraries will stick to MPL. *Bruno C. O. Dutra*