Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-02-22 19:45:56

>
> 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*