Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-03-02 12:23:04

2016-03-01 12:36 GMT-03:00, edouard_at_[hidden] <edouard_at_[hidden]>:
>> As a modern approach to the same task that Boost.MPL was meant to address,
>> I
>> don't believe Boost would benefit at all from yet another TMP library
>> that
>> would essentially compete with Boost.MPL and even Boost.Hana in some
>> cases,
>> specially as maintainers of older code that depends on Boost.MPL would
>> have
>> to go through major refactoring efforts in order to benefit from such an
>> addition to Boost. I would like to propose something different instead.
>>
>> My proposal is to make Metal officially into a new revision of Boost.MPL's
>> API,
>> essentially MPL2 as the original proposal by Robert Ramey put it, merging
>> both
>> into one single TMP library. The idea would be to provide a thin proxy for
>> the
>> current Boost.MPL API which would have two backends configurable by
>> preprocessor switches: the original implementation and a another one
>> based
>> on Metal. This way older code using Boost.MPL could see immediate gains
>> on
>> performance by selecting the newer backend on supported compilers, while
>> at
>> the same time legacy code maintained on older compilers could still rely
>> on
>> Boost.MPL's impressive ability to run virtually anywhere. On the other
>> hand,
>> newer projects interested on pure type computations would have the newer
>> API entirely available to them.
>
> I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03
> metaprogramming library. If you need a C++11/14/17 TMP, then you need
> another library.
>
> In Brigand we looked at Boost.MPL in terms of features, like, you should be
> able to do everything you do with Boost.MPL with Brigand, but we didn't look
> at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a
> different language than C++ 03. It would be like writing a C++ 11 Json
> library and bothering about how it's been implemented in Python.

I believe we concur then. I should stress that Metal is an entirely
new TMP library written from scratch to take advantage of everything
C++11 has to offer, no restrictions imposed.

Metal’s only relation to Boost.MPL is the fact it has been designed so
as to _ look_ very much like Boost.MPL from the point of view of the
user, that is, it is built around similar concepts and provides
roughly the same metafunctions, so, in this sense, I argue it is a
natural successor to Boost.MPL.

> If you want to change a single line of Boost.MPL or add a wrapper you will
> spend a lot of time in back testing and will never be 100% sure it's
> retro-compatible. A lot of critical code, out there, depends on Boost.MPL
> and I don't think it's a good thing to add friction in the upgrade path. I
> also submit that Boost library authors currently using Boost.MPL will go
> after you with pitchforks if you break anything.
>
> Having a proxy that switches backend transparently looks like a good idea
> but is, in my opinion, very hard to do for little to no benefit.

I very much share your concern. It poses a considerable risk to inpact
in any way a core library such as Boost.MPL that has been in use for
over a decade now and that is why I turn to the community for
discussing this proposal.

I do believe it is possible to make sure the alternative
implementation of Boost.MPL honours every requirement of its
documentation with reasonable confidence, since it is easier for a
pure functional language, but it is also possible that some code out
there still breaks due to their reliance on undocumented behaviour
(been there done that). Now should Boost care for such cases?

> You might be surprised to learn than in real-life project switching from
> Boost.MPL to a faster "more modern" MPL doesn't yield any speed improvement
> unless you change the way your use that MPL. I am speaking from experience
> because when we switched from Boost.MPL to Brigand in quasardb, we had to
> change a certain number of things to see any impact in terms of compilation
> speed. Whereas if you compile side by side a Boost.MPL program and a Brigand
> program there is easily one order of magnitude in speed gain with Brigand.

That is not true in general, for it depends on how Boost.MPL is used.

More specifically, if sequences are explicitly folded, iterators are
explicitly tracked or any other mandatorily recursive algorithm is
used, then I agree with you that using Metal as a backend for
Boost.MPL would only bring marginal improvements at most.

However, if mostly algorithms that may be somehow expressed in terms
of variadic template expansion are used, such as transform, find,
remove, replace, contains, partition, etc., then most surely dramatic
improvements would be perceived.

Since you mentioned performance, I would like to clarify that Metal
was not designed to be the fastest TMP library out there, nor it is
advertised as such, rather I pose that it is just fast enough for
mainstream metaprogramming and that’s already a couple of orders of
magnitude faster than Boost.MPL in most cases. That means I actively
avoided such optimizations as fast tracked recursion and unrolling,
which tend to demand additional template specializations, which
clutter the code base and thus impair clarity and maintenance. My
goals were instead make sure Metal was as easy as possible to maintain
and that is why I believe it is a good fit for Boost. I invite you and
everyone else to briefly browse through the source code [1], so you
can see I did try hard to keep it simple and easy to understand.

> I think if people want to do C++ 11/14/17 TMP they might as well start with
> new principles and I don't think it's worth annoying Boost.MPL users with
> evolution that, in the end, might not be as substantial as you infer.
>
> The other advantage of not extending/modifying Boost.MPL is that nothing
> prevents you to progressively switch from one library to the other. For
> example, progressively migrate the code from Boost.MPL to Boost.Hana.

I designed Metal around the concept of TMP because I do believe it is
expressive and cleaner when all one needs to do is manipulate some
types, express a few concepts and trigger SFINAE accordingly. In other
words, I consider TMP a feature, not a constraint.

> This is of course not an opinion on the quality of your Metal library, just
> a comment on its relation with Boost.MPL.

I appreciate your comments and I hope I could clarify a few aspects
regarding the design of Metal.

[1]: https://github.com/brunocodutra/metal/tree/master/include/metal
-- 
Bruno Dutra