Boost logo

Boost :

Subject: Re: [boost] About all these metaprogramming libraries
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-03-18 23:04:56

Le 18/03/2017 à 23:08, Peter Dimov via Boost a écrit :
> Vicente J. Botet Escriba wrote:
>> * do we want (can) to use as (HOMF) high-order meta-functions? if we
>> nedd them at all). IIUC, Peter library doesn't works with HOMFs.
>> * do we want a Hana style with "concepts" and with customizations? Do
>> we want other data type than type lists? IIUC Peter's library works
>> only with template aliases as data types and almost variadic class
>> template with type parameters is a good candidate for a type list
>> (even std::variant :( )
> These two are the distinguishing features of mp11. All other libraries
> have chosen differently. To clarify, the mp11 approach does support
> higher-order metaprogramming, but it chooses to make the ordinary case
> easier at the expense of the HOMF case, which is made harder, whereas
> the other libraries choose to make HOMF easier, at the expense of
> taking quoted metafunctions as arguments, which requires aliases to be
> quoted.
> mp11, in contrast, requires quoted metafunctions to be de-quoted
> (Q::invoke) when passed to algorithms.
I have the impression that mp11 cannot use the meta function returned by
a function as a parameter of an algorithm, but I'm missing something
that it should be evident to you. How can we define a compose
meta-function that could be used later as parameter?

algo<dt, compose<mf1, mf2>>
> To clarify further, std::variant<T...> is absolutely a supported
> typelist in mp11. If you have a std::variant V, you can remove the
> duplicate types from it with mp_unique<V>. This is again a deliberate
> design decision which keeps simple uses simple at the expense of
> making more complicated uses more complicated. With the other
> libraries, to remove the duplicates from a variant, you first have to
> convert it to the native typelist type, apply 'unique', then convert
> back to std::variant.
I know. I just find it weird to take std::variant as a data type that
models type list. I agree with you that given the definition you have
used in mp11 (it is also the case of Brigand), std::variant models a
mp11 type list.
I'm not saying that it is not useful and I suspect that it should reduce
the compile time.

My main concern is that Boost.Hana has more data types than type list
and that the algorithms are associated to concepts. IIUC, mp11 has only
one concept (variadic template) and all the algorithms we can define on
this very rich data structure. Maybe you are right and this is all we
need. At a first glance I would prefer a meta library that is based on
the design of Hana. I'm not saying here that I want the mixity of type
and values.
Of course, if the compile times are very different I could change my
first impression.

Boost list run by bdawes at, gregod at, cpdaniel at, john at