Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-02-29 07:52:30

2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller_at_[hidden]>:
>
>
>> Gesendet: Montag, 29. Februar 2016 um 00:17 Uhr
>> Von: "Bruno Dutra" <brunocodutra_at_[hidden]>
>> An: boost_at_[hidden]
>> 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-expression.html
[2]: http://brunocodutra.github.io/metal/#duality
[3]: http://brunocodutra.github.io/metal/#concepts

Regards,
Bruno Dutra