Quantcast

Formal Review Request: mp11

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Formal Review Request: mp11

Boost - Dev mailing list
I'd like to request a review for mp11, a simple C++11 metaprogramming
library.

The library implements the approach outlined in my two articles

http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html
http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

and is available at

https://github.com/pdimov/mp11/

It supports g++ 4.9 and above, clang 3.6 and above, msvc-12.0, 14.0, 14.1.

The library is in Boost format and is intended to be placed in libs/mp11 in
a Git clone of Boost.

There is documentation in doc/html/mp11.html, it can be viewed locally, or
with

https://htmlpreview.github.io/?https://github.com/pdimov/mp11/master/doc/html/mp11.html

Please excuse the lack of .css in that link.

Thanks in advance for any interest, comments or suggestions.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
On 03/17/2017 03:06 PM, Peter Dimov via Boost wrote:

> https://github.com/pdimov/mp11/

A few comments...

Most algorithms take the typelist as the first argument, but others
do not, e.g. mp_transform<F, L...>. If possible, I would like to see
all algorithms take typelist as the first argument. It looks like the
current order is dictated by the requirements of mp_tranform_impl.
Would it be possible to swap the types where the algorithm is
declared? For example:

   template<class L, template<class...> class F> using mp_transform =
typename detail::mp_transform_impl<F, L>::type;

Apropos mp_transform, would it be possible to extend it such that we
can pass a type-trait directly to it? For example:

   using const_list = mp_transform<std::add_const, typelist>;

instead of using std::add_const_t. The reason I ask is that I have
lots of my own domain-specific type-traits that does not come with
a _t version, so this is mainly for convenience.

The reference documentation is a bit terse and obscure. For example, the
documentation for mp_find tells us in a convoluted way that it returns
the index of a type in a typelist. It could also mention that it is
the dual algorithm to mp_at, which returns a type at an index in a
typelist.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Bjorn Reese wrote:

> Most algorithms take the typelist as the first argument, but others do
> not, e.g. mp_transform<F, L...>. If possible, I would like to see all
> algorithms take typelist as the first argument.

It's not possible for L... to be first. Note the ellipsis.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/18/2017 02:33 PM, Peter Dimov via Boost wrote:
> Bjorn Reese wrote:
>
>> Most algorithms take the typelist as the first argument, but others do
>> not, e.g. mp_transform<F, L...>. If possible, I would like to see all
>> algorithms take typelist as the first argument.
>
> It's not possible for L... to be first. Note the ellipsis.

Notice that I removed them :)

The documentation states that "data structures are lists of the form
L<T...>" so why is L... needed in mp_transform?

I just the type-swapping trick with mp_list and std::tuple, and both
worked fine.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Bjorn Reese wrote:

> Apropos mp_transform, would it be possible to extend it such that we can
> pass a type-trait directly to it? For example:
>
>    using const_list = mp_transform<std::add_const, typelist>;
>
> instead of using std::add_const_t. The reason I ask is that I have lots of
> my own domain-specific type-traits that does not come with a _t version,
> so this is mainly for convenience.

That's unfortunately not possible because mp_transform<std::add_const,
mp_list<int, float>> is perfectly valid and yields mp_list<add_const<int>,
add_const<float>>. I can add

template<template<class...> class T> struct mp_quote_trait
{
    template<class... U> using invoke = typename T<U...>::type;
};

that would allow

    mp_transform<mp_quote_trait<std::add_const>::invoke, L>

but that's not much of an improvement. _t is the way to go with mp11.

> The reference documentation is a bit terse and obscure.

That it is. I'm gradually improving it bit by bit when I find time to work
on it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Bjorn Reese wrote:

> On 03/18/2017 02:33 PM, Peter Dimov via Boost wrote:
> > Bjorn Reese wrote:
> >
> >> Most algorithms take the typelist as the first argument, but others do
> >> not, e.g. mp_transform<F, L...>. If possible, I would like to see all
> >> algorithms take typelist as the first argument.
> >
> > It's not possible for L... to be first. Note the ellipsis.
>
> Notice that I removed them :)
>
> The documentation states that "data structures are lists of the form
> L<T...>" so why is L... needed in mp_transform?

mp_transform is variadic, it works on more than one list.

    mp_transform<std::pair, mp_list<int, float>, mp_list<char, double>>

->

    mp_list<std::pair<int, char>, std::pair<float, double>>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/18/2017 02:55 PM, Peter Dimov via Boost wrote:

> mp_transform is variadic, it works on more than one list.

Ok. How about having two versions? One that takes a single typelist
(at the beginning) and one that takes an arbitrary number. The latter
should probably be named differently to indicate that its arguments
deviate from the rest of the algorithms (e.g mp_multi_transform.)

>    mp_transform<std::pair, mp_list<int, float>, mp_list<char, double>>
>
> ->
>
>    mp_list<std::pair<int, char>, std::pair<float, double>>

Oh, a zip. That looks useful. You should add that example to the
documentation.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> On Mar 17, 2017, at 8:06 AM, Peter Dimov via Boost <[hidden email]> wrote:
>
> I'd like to request a review for mp11, a simple C++11 metaprogramming library.
>
> The library implements the approach outlined in my two articles
>
> http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html
> http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html
>
> and is available at
>
> https://github.com/pdimov/mp11/
>
> It supports g++ 4.9 and above, clang 3.6 and above, msvc-12.0, 14.0, 14.1.

Whats the reason for not supporting gcc 4.8?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Paul Fultz II wrote:
> > https://github.com/pdimov/mp11/
> >
> > It supports g++ 4.9 and above, clang 3.6 and above, msvc-12.0, 14.0,
> > 14.1.
>
> Whats the reason for not supporting gcc 4.8?

gcc 4.7 and 4.8 almost work. 4.8 fails a single test, mp_replace_if, because
it for some reason strips the const qualifiers from the elements there. gcc
4.7 fails one additional test, mp_defer, that isn't critical and the error
is probably in the test itself.

https://travis-ci.org/pdimov/mp11/builds/207959624

I can #ifdef the mp_replace_if test (or casually remove the top-level
consts, whistling innocently and pretending not to know anything about the
matter) and declare 4.8 supported, but the compiler bug seems likely enough
to bite someone. msvc-12.0 is much buggier, but when it works, it doesn't
produce wrong results.

TL;DR they work and will likely continue to work, I just don't support them
"officially" at the moment.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 17/03/2017 à 15:06, Peter Dimov via Boost a écrit :

> I'd like to request a review for mp11, a simple C++11 metaprogramming
> library.
>
> The library implements the approach outlined in my two articles
>
> http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html
> http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html
>
> and is available at
>
> https://github.com/pdimov/mp11/
>
>
> There is documentation in doc/html/mp11.html, it can be viewed
> locally, or with
>
> https://htmlpreview.github.io/?https://github.com/pdimov/mp11/master/doc/html/mp11.html 
>
>
> Please excuse the lack of .css in that link.
>
> Thanks in advance for any interest, comments or suggestions.
Hi,

I believe that there is a missing tutorial/design rationale section that
could be filled with some parts of your articles.

About the infamous tuple_cat challenge. tuple_cat doesn't append. tuple
cat construct a tuple with the elements of its tuple-like parameters (I
know that the standard wording doesn't says that exactly, as it accepts
only standard tuple-like types - I've written a proposal so that it can
take in account any product type including every type that is supported
by structure binding. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0327r1.pdf).
Examples of product types that don't follow the template aliases pattern
are T[N], array<T,N>, struct {...};
I'm not saying that mp_append is not useful and it surely is much more
efficient, but the description in your paper doesn't solves yet the
problem with concatenation of arbitrary product types. We would need to
obtain to obtain the type list associated to to each product type, then
append them and the rename to tuple.


About transform. I believe that we should have a simple unary
transform<TL, F>. What you have mp11::transform is what we use to name
fmap in functional languages.
As C++ is variadic it can be extended naturally to variadic meta-functions.
     mp_fmap<F<Ps...>, TLs...>.


About your mp_count example. Compare your definition with this the HOF one


     template <class TL, class V>
         using mp_count_if<TL, P> = mp_plus<transform<TL, P>;

     template <class TL, class V>
         using mp_count<TL, V> = mp_cont_if<TL, is_same_t<_1,V>>;

I don't know if this could have worst or better performances, but IMHO,
it is much more readable and simpler than your definitions.


BTW, your mp_plus doesn't take a type list as parameter.

About mp_contains. I've not yet finished the second article yet. IMO, we
need different concepts as we can have different implementations. I
believe mp_contains is an example where we can have different
implementations for type list and for type set. I recognize however that
most of the meta-programming is done with type lists.

About C++11, C++14, C++17.  I believe that meta-programming can profit a
lot of C++17 fold expressions. I believe that a new meta library should
use these features as implementation details when available and when the
performances are increased.


Best,
Vicente



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Vicente J. Botet Escriba wrote:

> About the infamous tuple_cat challenge. tuple_cat doesn't append. tuple
> cat construct a tuple with the elements of its tuple-like parameters...

That's quite true. The tuple_cat implementation in the article is a
straightforward reimplementation of Eric's tuple_cat, to illustrate the
difference in styles. It fixes one limitation of the original, but others
remain. Specifically, it doesn't work when the arguments are const
qualified, when the tuple elements are move-only (although this is a defect
in std::get), or for tuple-likes apart from std::pair.

Fixing those defects one by one:

1. tuple<unique_ptr<int>> can be fixed by replacing

template<class R, class...Is, class... Ks, class Tp>
R tuple_cat_( mp_list<Is...>, mp_list<Ks...>, Tp tp )
{
    return R{ std::get<Ks::value>(std::get<Is::value>(tp))... };
}

with

template<class R, class...Is, class... Ks, class Tp>
R tuple_cat_( mp_list<Is...>, mp_list<Ks...>, Tp tp )
{
    return R{ std::get<Ks::value>(std::get<Is::value>(std::move(tp)))... };
}

This shouldn't be necessary though; it's std::get that is broken here.

2. const-qualified tuples:

template<class... Tp,
    class R = mp_append<std::tuple<>, typename
std::remove_reference<Tp>::type...>>
    R tuple_cat( Tp &&... tp )

needs to be replaced with

template<class T> using remove_cv_ref =
std::remove_cv_t<std::remove_reference_t<T>>;

template<class... Tp,
    class R = mp_append<std::tuple<>, remove_cv_ref<Tp>...>>
    R tuple_cat( Tp &&... tp )

and the same substitution needs to be done for

    using list1 = mp_list<mp_rename<typename
std::remove_reference<Tp>::type, mp_list>...>;

3. tuple-like types:

template<class... Tp,
    class R = mp_append<std::tuple<>, remove_cv_ref<Tp>...>>
    R tuple_cat( Tp &&... tp )

needs to be further massaged as follows:

template<class N, class T> using element_ = std::tuple_element_t<N::value,
T>;
template<class T> using from_tuple_like = mp_product<element_,
mp_iota<std::tuple_size<T>>, mp_list<T>>;

template<class... Tp,
    class R = mp_append<std::tuple<>,
from_tuple_like<remove_cv_ref<Tp>>...>>
    R tuple_cat( Tp &&... tp )

and similarly for list1:

    using list1 = mp_list<from_tuple_like<remove_cv_ref<Tp>>...>;

With these changes, this now works:

{
    std::array<int, 2> const t1{ 1, 2 };
    std::array<float, 3> const t2{ 3.0f, 4.0f, 5.0f };
    std::array<std::unique_ptr<int>, 1> t3{ std::unique_ptr<int>{ new
int } };

    using expected = std::tuple<int, int, float, float, float,
std::unique_ptr<int>>;

    auto result = ::tuple_cat( t1, std::move( t2 ), std::move( t3 ) );

    static_assert( std::is_same<decltype(result), expected>::value, "" );

    PRINT_TYPE( decltype(result) );

    print_tuple( result );
}


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vicente J. Botet Escriba wrote:

> About your mp_count example. Compare your definition with this the HOF one
>
>      template <class TL, class V>
>          using mp_count_if<TL, P> = mp_plus<transform<TL, P>;

First, you need to keep in mind that the code in the article compiled and
worked at the time on the compilers that I had available, which included
Visual Studio 2013. Using mp_transform was a good way to crash MSVC and
remains so to this day, which is why the implementations often inline it by
hand.

Second, the above doesn't work because P<T>::value is allowed to be 42.

>      template <class TL, class V>
>          using mp_count<TL, V> = mp_cont_if<TL, is_same_t<_1,V>>;

This - assuming that is_same_t is a template alias - cannot be made to work.
Template aliases are evaluated eagerly and is_same_t<_1, V> gives you
mp_true or mp_false depending on whether V is _1 (the literal _1) or not.

You either have to use std::is_same<_1, V> and make the algorithms take and
evaluate such lambdas by replacing placeholders and looking at ::type, or
you need to bind or curry is_same_t. mp_bind<is_same_t, _1, V>::invoke, if
it existed (it's a few lines, I'll probably add it) or mp_quote<is_same_t,
V>::invoke.

(I'm considering renaming ::invoke to something shorter such as ::fn.)

> BTW, your mp_plus doesn't take a type list as parameter.

It doesn't. There's an annoying dilemma here as most functions are useful in
either form. mp_second<L> for instance takes a list, but mp_second<T...>
would also have been useful. Not sure what to do here.

> About mp_contains. I've not yet finished the second article yet. IMO, we
> need different concepts as we can have different implementations. I
> believe mp_contains is an example where we can have different
> implementations for type list and for type set.

It does, see mp_contains and mp_set_contains in the actual mp11 source. The
latter requires the elements to be unique, although the data structure is
still a list. I like Lisp.

> About C++11, C++14, C++17.  I believe that meta-programming can profit a
> lot of C++17 fold expressions.

That belief is not necessarily true, but there are places where fold
expressions are obviously useful, such as mp_plus. mp_fold can also be
rewritten in their terms, but the performance gains are disappointingly
small, although it does considerably increase the list size limit that can
be handled without the compiler crashing.

We'll add BOOST_NO_CXX17_FOLD_EXPRESSIONS at some point, presumably. Support
is currently a bit hard to detect as Clang doesn't define an __is_feature
for it. (I already had to make creative use of fold expressions to work
around a Clang 3.9+ bug with mp_find.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Mar 18, 2017 at 2:55 PM, Peter Dimov via Boost <
[hidden email]> wrote:

> Bjorn Reese wrote:
>
> On 03/18/2017 02:33 PM, Peter Dimov via Boost wrote:
>> > Bjorn Reese wrote:
>> >
>> >> Most algorithms take the typelist as the first argument, but others do
>> >> not, e.g. mp_transform<F, L...>. If possible, I would like to see all >>
>> algorithms take typelist as the first argument.
>> >
>> > It's not possible for L... to be first. Note the ellipsis.
>>
>> Notice that I removed them :)
>>
>> The documentation states that "data structures are lists of the form
>> L<T...>" so why is L... needed in mp_transform?
>>
>
> mp_transform is variadic, it works on more than one list.


Is it truly variadic? Does it work for more than 3 lists?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Bruno Dutra wrote:

> > mp_transform is variadic, it works on more than one list.
>
> Is it truly variadic? Does it work for more than 3 lists?

The actual implementation in mp11 doesn't work on more than 3 lists at the
moment, but that's a defect that will eventually be fixed. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 19/03/2017 à 12:06, Peter Dimov via Boost a écrit :

> Vicente J. Botet Escriba wrote:
>
>> About your mp_count example. Compare your definition with this the
>> HOF one
>>
>>      template <class TL, class V>
>>          using mp_count_if<TL, P> = mp_plus<transform<TL, P>;
>
> First, you need to keep in mind that the code in the article compiled
> and worked at the time on the compilers that I had available, which
> included Visual Studio 2013. Using mp_transform was a good way to
> crash MSVC and remains so to this day, which is why the
> implementations often inline it by hand.
>
> Second, the above doesn't work because P<T>::value is allowed to be 42.
I'm not sure this should be the case, but if it was, then, the predicate
passed to transform should be a little bit adapted.
|mp_plus<|||mp_transform_f<TL, |compose<mp_to_bool_f, P>|>

>
>>      template <class TL, class V>
>>          using mp_count<TL, V> = mp_count_if<TL, is_same_t<_1,V>>;
>
> This - assuming that is_same_t is a template alias - cannot be made to
> work. Template aliases are evaluated eagerly and is_same_t<_1, V>
> gives you mp_true or mp_false depending on whether V is _1 (the
> literal _1) or not.
>
> You either have to use std::is_same<_1, V> and make the algorithms
> take and evaluate such lambdas by replacing placeholders and looking
> at ::type, or you need to bind or curry is_same_t. mp_bind<is_same_t,
> _1, V>::invoke, if it existed (it's a few lines, I'll probably add it)
> or mp_quote<is_same_t, V>::invoke.
>
You know what I mean. is_same<_1,V> should be a meta-function class.
Being able to use HOF makes meta-programming code simpler.
I was not thinking on making the algorithms do any analysis of the place
holders. I was just thinking on providing some specializations

template <class T>
struct is_same<_1, T> {
     template <class U>
     using invoke = is_same<U,T>;
};

or using something like Meta lambdas

template <class T> struct is_same<_1, T> : lambda<_1,
lazy::is_same<_1,T> {};


mp_quote<is_same_t, V> would work as well.
> (I'm considering renaming ::invoke to something shorter such as ::fn.)

BTW, mp_quote does more than quoting. It is doing some binding. I've
proposed the names it bind_front/bind_back that follows the new
bind_front/bind_back for normal programming
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0356r0.html)
Have you considered the possibility to provide algorithms taking HOF as
well as template aliases?
>
>> BTW, your mp_plus doesn't take a type list as parameter.
>
> It doesn't. There's an annoying dilemma here as most functions are
> useful in either form. mp_second<L> for instance takes a list, but
> mp_second<T...> would also have been useful. Not sure what to do here.
Maybe we need both.

>
>> About mp_contains. I've not yet finished the second article yet. IMO,
>> we need different concepts as we can have different implementations.
>> I believe mp_contains is an example where we can have different
>> implementations for type list and for type set.
>
> It does, see mp_contains and mp_set_contains in the actual mp11
> source. The latter requires the elements to be unique, although the
> data structure is still a list. I like Lisp.
>
Yes, I've see it now.

BTW I'm missing how we build a mp set. It is with inherit<>? Could we
have an empty set?
Why mp11 provides two ways to insert elements in a set push_back and
push_front?
I guess that we can use all the other mp_ functions that work for type
list with type set.


>> About C++11, C++14, C++17.  I believe that meta-programming can
>> profit a lot of C++17 fold expressions.
>
> That belief is not necessarily true, but there are places where fold
> expressions are obviously useful, such as mp_plus. mp_fold can also be
> rewritten in their terms, but the performance gains are
> disappointingly small, although it does considerably increase the list
> size limit that can be handled without the compiler crashing.
>
> We'll add BOOST_NO_CXX17_FOLD_EXPRESSIONS at some point, presumably.
> Support is currently a bit hard to detect as Clang doesn't define an
> __is_feature for it. (I already had to make creative use of fold
> expressions to work around a Clang 3.9+ bug with mp_find.)
I understand that we are not yet ready to write portable C++17 code.

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Vicente J. Botet Escriba wrote:

> You know what I mean. is_same<_1,V> should be a meta-function class.

I didn't, not because I'm being deliberately obtuse, but because different
metaprogramming libraries have taken different approaches to what
constitutes a metafunction class. What they have in common is that they take
metafunction classes (instead of template aliases as mp11 does) which they
then evaluate internally with their eval/invoke primitive, but how invoke
handles placeholders differs from library to library.

> BTW, mp_quote does more than quoting. It is doing some binding.

Originally it did just quote, then I noticed that the extension to partial
application (bind_front) is straightforward. In the simple case mp_quote<F>
it still quotes.

> BTW I'm missing how we build a mp set.

Usually you start with an empty mp_list<> and mp_set_push_back things into
it; the other case is when you have an existing list L and convert it to a
set with mp_unique<L>.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vicente J. Botet Escriba wrote:

> Have you considered the possibility to provide algorithms taking HOF as
> well as template aliases?

In the middle of a discussion about whether we need four metaprogramming
libraries, you are asking me to provide a fifth. :-)

mp11 is fundamentally based on template aliases. Yes, this is constraining
for people who are accustomed to higher-order programming. The point is not
to be all things to all people; higher-order programming is well covered by
the other contenders in the field.

I realize that this way of thinking does not sit well with some that would
prefer we settle on a single library.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Mar 19, 2017 at 6:51 PM, Vicente J. Botet Escriba via Boost <
[hidden email]> wrote:

> Have you considered the possibility to provide algorithms taking HOF as
> well as template aliases?


This is a false dilemma, these are _not_ mutually exclusive, one can have
the exact same lazy API with eager alias templates alone by using bind<>
instead.

Following is a snippet using Metal, that implements the cartesian product
of a List by itself. Notice how the upper case are in fact just lazy
adaptors to the eager algorithms metal provides (lower case letters), all
written using eager alias templates.

using namespace metal;
template<typename... args>using Transform = bind<lambda<transform>, args...>;
template<typename... args>using Bind = bind<lambda<bind>, args...>;
template<typename arg>using Quote = bind<lambda<bind>, args>;
template<typename x>using product = apply<
  lambda<join>,
  transform<Transform<Bind<quote<lambda<list>>, Quote<_1>, quote<_1>>,
quote<x>>, x>
>;



Bruno Dutra

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/18/2017 02:50 PM, Peter Dimov via Boost wrote:

> but that's not much of an improvement. _t is the way to go with mp11.

As _t for <type_traits> is C++14, what is the solution for C++11?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Formal Review Request: mp11

Boost - Dev mailing list
Bjorn Reese wrote:
> On 03/18/2017 02:50 PM, Peter Dimov via Boost wrote:
>
> > but that's not much of an improvement. _t is the way to go with mp11.
>
> As _t for <type_traits> is C++14, what is the solution for C++11?

Well, you write the _t versions yourself on an as-needed basis, I suppose.
:-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...