Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-02-22 18:52:39

On 2/22/2015 5:36 PM, Louis Dionne wrote:
> Bruno Dutra <brunocodutra <at> gmail.com> writes:
>
>>> My concern about hana is that it
>>> seems to have evolved way beyond what MPL does and so wouldn't
>>> serve as a "drop-in" improvement.  I don't know about Eric's effort
>>> but I believe he's said he can't bring to the level of a boost library
>>> and no one has expressed any interest.
>>
>> That's exactly the point I was trying to make. Hana is awesome, but it
>> doesn't fit as a replacement for MPL, simply because it was meant for
>> a different purpose. I see no reason why they shouldn't live side by
>> side, each filling its specific niche.
>
> I'm a bit late in the game because this thread has gone under my radar;
> please excuse that, I was busy working on Hana :-).
>
> 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.
>
> 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.

Hana can be a completely differently designed library from MPL, as you 
have expressed it, without negating its value in any way.

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

Numerous Boost libraries currently use MPL. If you want to have Hana as 
a Boost library, if it is accepted after review, I think you will have 
to get used to the idea that Boost will have more than one 
metaprogramming library. If Hana proves popular enough with 
metaprogrammers they will switch away from MPL to Hana.

I do not know what you mean by "two metaprogramming libraries
living side by side" but I believe that two libraries whose purposes are 
similar but whose programming interfaces are different is never a 
detriment to Boost as long as both are quality libraries which other 
programmers find useful.

>
> As a final note: if you have comments, doubts or other thoughts about Hana,
> please express them by either posting on this list or (even better) opening
> a GitHub[2] issue. If I know what people need, I can make sure that Hana
> satisfies them properly.
>
> I will be asking for an informal review shortly, so stay tuned.
>
> Regards,
> Louis
>
> [1]: http://ldionne.github.io/hana
> [2]: https://github.com/ldionne/hana