Re: [boost] [MPL] A Proposal

2016-02-29 6:37 GMT-03:00, Jens Weller :

...

Gesendet: Montag, 29. Februar 2016 um 00:17 Uhr Von: "Bruno Dutra" An: boost@lists.boost.org Betreff: [boost] [MPL] A Proposal

Dear Community,

[snip]

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.

This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources.

Whats the difference between your metal library and the Brigand library by Edouard Aligand and Joel Falcou, also written for a similar purpose: to replace boost.MPL?

I must admit I wasn’t aware of the existence of Brigand up until now. At a first glance I can see that Brigand, just like Eric Niebler's Meta, departs from the lazy design of Boost.MPL and Metal in that it appears to impose eager evaluation of metafunctions instead of requiring explicit evaluation via typename $::type. It might be that Boost.MPL was so designed because at the time there were no alias templates, but the lazy design does have several advantages in my opinion. First of all, it enables the natural definition of Lambdas as unevaluated metafunctions [1]. Moreover, by defining lists as simply unevaluated metafunctions, Metal essentially erases the distinction between data structures and the algorithms themselves [2]. This interesting property known as Homoiconicity is often credited for the expressiveness and flexibility of Lisp. Finally, unevaluated metafunctions can also be regarded as optionals that either define a nested ::type, if they can be successfully computed, or not, if some precondition is not met, e.g. trying to access an element of an empty list. This way metafunctions may be safely tested using metal::is_just before being evaluated, without requiring explicit use of SFINAE. Besides, the verbosity of typing typename $::type can be totally overcome by using the C++14 notation and defining alias templates ended by _t as eager versions of metafunctions. Please refer to [3] for the definition of lists, optionals, expressions (metafunctions), etc., for an overall idea of Metal's design. Of course this is just a very shallow and biased comparison between Metal and Bringad. I’ll be sure to watch their presentation and better understand their approach before I can more accurately compare Metal with it.

Do you compile as fast as Brigand?

My next efforts will be directed toward developing a framework for running banchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes. [1]: http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/refmanual/lambda-expressio... [2]: http://brunocodutra.github.io/metal/#duality [3]: http://brunocodutra.github.io/metal/#concepts Regards, Bruno Dutra