Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-02-22 17:36:15

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.

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.

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