Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-02 13:03:14

On 3/2/2016 12:23 PM, Bruno Dutra wrote:
> 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?

No. Any code using undocumented parts of a Boost library, or 
undocumented behavior which just happens to work with some release of 
some Boost library, is on its own. That can't be the concern of a 
library developer IMO.

However the responder has a good point that you need to be thorough in 
testing any change to Boost.MPL since it is such a core library of 
Boost. If you need help in testing MPL in an environment which may be 
difficult for you to replicate don't be afrad to ask on this mailing list.

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