About all these metaprogramming libraries

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

About all these metaprogramming libraries

Louis Dionne
Dear Boost,

We've seen two metaprogramming libraries ask for a formal review on the list recently. I expect a third (Brigand) might join the party soon, and maybe even a fourth (Eric Niebler's meta). I think it would be wise to have a plan for how we're going to deal with this.

Before going further, I'd also like to clear something out. Some people have asked whether "classic" metaprogramming libraries still had their place given that we now have Hana. As the author of Hana, I think the answer is yes. While Hana is (IMHO) easier to use and more powerful, it also has an important shortcoming. Hana is too slow when dealing with very large inputs. This is due to the fact that it can also handle values, which is much heavier than dealing with types only. This can be alleviated to some extent, but the truth is that our execution model (the compiler) simply has to do more work when handling values.

Hence, I think Boost does need a modern classic TMP library to handle these cases where a library writer needs to handle gigantic type lists. I think marketing such a library as an advanced tool for library writers would be a service to the overall C++ community, but that's an orthogonal concern.

However, Boost needs one such library, not four. I think we can't just do 4 reviews and include all the libraries that pass in Boost; that would be a huge disservice to our users, who will be left with the burden of choosing. Heck, if we can't even make our mind, how can they?

So, how do we pick? Have we ever been in a similar situation where we have multiple competing libraries solving _exactly_ the same problem?

Louis
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About all these metaprogramming libraries

Boost - Dev mailing list
Hi Louis,

>We've seen two metaprogramming libraries ask for a formal review on the list recently. I expect a third (Brigand) might join the party soon, and maybe even a fourth (Eric Niebler's meta). I think it would be wise to have a plan for how we're going to deal with this.

I am one of the authors of Brigand (https://github.com/edouarda/brigand), and it's true we're considering submitting it. This is upon request by Boost library authors who would like to use Brigand to reduce the compilation time of their libraries. If the submission is deemed inappropriate or useless it will not happen.

>Hence, I think Boost does need a modern classic TMP library to handle these cases where a library writer needs to handle gigantic type lists. I think marketing such a library as an advanced tool for library writers would be a service to the overall C++ community, but that's an orthogonal concern.

I agree with you. I also think that just patching Boost.MPL to make it leverage C++ 11 will not be sufficient. That's how Brigand got started and very quickly we realized we were at a dead end. Then I read Peter Dimov's article and realized there was a better way. :-)

>However, Boost needs one such library, not four. I think we can't just do 4 reviews and include all the libraries that pass in Boost; that would be a huge disservice to our users, who will be left with the burden of choosing.
>Heck, if we can't even make our mind, how can they?

I'm afraid the main produce of 4 reviews might be an extraordinary amount of bike shedding.

>So, how do we pick? Have we ever been in a similar situation where we have multiple competing libraries solving _exactly_ the same problem?

Does a decision need to be taken urgently? The aforementioned libraries are currently available and ready to be used. To me, the inclusion into Boost is more about the process than the inclusion itself. The process will raise questions and issues and shed some light on unsuspected usage scenarii.

At CppCon we discussed if the language and the standard library needed improvements to make TMP even more useful, convenient and faster.

I submit discussing what kind of TMP library should be added to Boost will be very beneficial.

-Edouard

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Louis Dionne
Le 18/03/2017 à 21:32, Louis Dionne via Boost a écrit :

> Dear Boost,
>
> We've seen two metaprogramming libraries ask for a formal review on the list
> recently. I expect a third (Brigand) might join the party soon, and maybe
> even a fourth (Eric Niebler's meta). I think it would be wise to have a plan
> for how we're going to deal with this.
>
> Before going further, I'd also like to clear something out. Some people have
> asked whether "classic" metaprogramming libraries still had their place
> given that we now have Hana. As the author of Hana, I think the answer is
> yes. While Hana is (IMHO) easier to use and more powerful, it also has an
> important shortcoming. Hana is too slow when dealing with very large inputs.
> This is due to the fact that it can also handle values, which is much
> heavier than dealing with types only. This can be alleviated to some extent,
> but the truth is that our execution model (the compiler) simply has to do
> more work when handling values.
>
> Hence, I think Boost does need a modern classic TMP library to handle these
> cases where a library writer needs to handle gigantic type lists. I think
> marketing such a library as an advanced tool for library writers would be a
> service to the overall C++ community, but that's an orthogonal concern.
>
> However, Boost needs one such library, not four. I think we can't just do 4
> reviews and include all the libraries that pass in Boost; that would be a
> huge disservice to our users, who will be left with the burden of choosing.
> Heck, if we can't even make our mind, how can they?
>
> So, how do we pick? Have we ever been in a similar situation where we have
> multiple competing libraries solving _exactly_ the same problem?
>
If there were several proposals, we could review all of them together.
We already did that for the thread/futures proposals.

I believe that some of the things we need to answer are:
* 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 :( )
* do we need lazy evaluation?
* do we need lambdas?
* do we want a C++11/C++14/C++17 library?
.... other you can think of.

However I see only one official proposal (mp11 - Peter Dimov), even if
there are other interesting libraries (as Meta, Brigand).


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: About all these metaprogramming libraries

Louis Dionne
In reply to this post by Boost - Dev mailing list
> If the submission is deemed inappropriate or useless it will not happen.

No, I think submitting Brigand for review is an excellent idea. We just have to figure out how to deal with 3-4 competing libraries in the same domain.

> I agree with you. I also think that just patching Boost.MPL to make it
> leverage C++ 11 will not be sufficient.

Agreed. We all tried that (me included a few years ago), and it's a bad idea.

> Does a decision need to be taken urgently?

Not as far as I'm concerned. I was just trying to handle the fact that right now, two authors have officially asked for a formal review. If we just happily do the reviews for those two libraries without thinking, we'll get into the scenario I'd like to avoid.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About all these metaprogramming libraries

Louis Dionne
In reply to this post by Boost - Dev mailing list
If there were several proposals, we could review all of them together. We already did that for the thread/futures proposals.
Ah, that's exactly the kind of thing I was looking for, thanks. So we've had previous experience with this.

* 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 :( )
As far as I can tell, none of the proposals have Hana-style customization points and concepts, but I see no reason to explicitly request that they provide them. I'm happy as long as there's some way to interoperating with other libraries.

However I see only one official proposal (mp11 - Peter Dimov), even if there are other interesting libraries (as Meta, Brigand).
You're right. I thought Bruno Dutra's Metal had been officially submitted, but not yet. In any case, it's just a matter of days or weeks.

Louis
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

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.


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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
Hi Peter,

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

We took the same approach. We have a native type list for convenience, but we also thought there was no reason to prevent direct manipulation of any kind of typelist. We also think it's best to keep the simple use cases straightfoward.

Kind regards.

-Edouard

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2017-03-18 22:49 GMT+01:00 Vicente J. Botet Escriba via Boost <
[hidden email]>:

> Le 18/03/2017 à 21:32, Louis Dionne via Boost a écrit :
>
>> Dear Boost,
>>
>> We've seen two metaprogramming libraries ask for a formal review on the
>> list
>> recently. I expect a third (Brigand) might join the party soon, and maybe
>> even a fourth (Eric Niebler's meta). I think it would be wise to have a
>> plan
>> for how we're going to deal with this.
>>
>> Before going further, I'd also like to clear something out. Some people
>> have
>> asked whether "classic" metaprogramming libraries still had their place
>> given that we now have Hana. As the author of Hana, I think the answer is
>> yes. While Hana is (IMHO) easier to use and more powerful, it also has an
>> important shortcoming. Hana is too slow when dealing with very large
>> inputs.
>> This is due to the fact that it can also handle values, which is much
>> heavier than dealing with types only. This can be alleviated to some
>> extent,
>> but the truth is that our execution model (the compiler) simply has to do
>> more work when handling values.
>>
>> Hence, I think Boost does need a modern classic TMP library to handle
>> these
>> cases where a library writer needs to handle gigantic type lists. I think
>> marketing such a library as an advanced tool for library writers would be
>> a
>> service to the overall C++ community, but that's an orthogonal concern.
>>
>> However, Boost needs one such library, not four. I think we can't just do
>> 4
>> reviews and include all the libraries that pass in Boost; that would be a
>> huge disservice to our users, who will be left with the burden of
>> choosing.
>> Heck, if we can't even make our mind, how can they?
>>
>> So, how do we pick? Have we ever been in a similar situation where we have
>> multiple competing libraries solving _exactly_ the same problem?
>>
>> If there were several proposals, we could review all of them together. We
> already did that for the thread/futures proposals.
>
> I believe that some of the things we need to answer are:
> * 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 :( )
> * do we need lazy evaluation?
> * do we need lambdas?
> * do we want a C++11/C++14/C++17 library?
> .... other you can think of.
>

Maybe, during the process, to get the additional insight, we sould request
of each of the candidates to compare the librearies with one another. They
are experts in the domain, and should be able to quickly identify different
tradeoffs taken by deiifferent libraries.

Regards,
&rzej;

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.
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: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Louis Dionne
Le 18/03/2017 à 22:52, Louis Dionne via Boost a écrit :
>> If there were several proposals, we could review all of them together. We
>> already did that for the thread/futures proposals.
> Ah, that's exactly the kind of thing I was looking for, thanks. So we've had
> previous experience with this.
Great.

>
>
>> * 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 :( )
> As far as I can tell, none of the proposals have Hana-style customization
> points and concepts, but I see no reason to explicitly request that they
> provide them. I'm happy as long as there's some way to interoperating with
> other libraries.
I'm not requesting that the meta libraries customize Hana concepts as
Boost.Hana has values.
I would like we discuss if we adapting those meta-concepts to the meta
world could be useful or not.
>
>> However I see only one official proposal (mp11 - Peter Dimov), even if
>> there are other interesting libraries (as Meta, Brigand).
> You're right. I thought Bruno Dutra's Metal had been officially submitted,
> but not yet. In any case, it's just a matter of days or weeks.
Who knows ;-)

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: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Louis Dionne
On Sat, Mar 18, 2017 at 10:52 PM, Louis Dionne via Boost <
[hidden email]> wrote:

>
> > If there were several proposals, we could review all of them together. We
> > already did that for the thread/futures proposals.
>
> Ah, that's exactly the kind of thing I was looking for, thanks. So we've
> had
> previous experience with this.
>

This is probably the most reasonable approach.


> > However I see only one official proposal (mp11 - Peter Dimov), even if
> > there are other interesting libraries (as Meta, Brigand).
>
> You're right. I thought Bruno Dutra's Metal had been officially submitted,
> but not yet. In any case, it's just a matter of days or weeks.
>

That is correct, I haven't formally submitted Metal yet, but that has been
in the works for the past couple of weeks and it is now a matter of days
like you said.

Bruno

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Mar 18, 2017 at 10:49 PM, Vicente J. Botet Escriba via Boost <
[hidden email]> wrote:

> Le 18/03/2017 à 21:32, Louis Dionne via Boost a écrit :
>
>> Dear Boost,
>>
>> We've seen two metaprogramming libraries ask for a formal review on the
>> list
>> recently. I expect a third (Brigand) might join the party soon, and maybe
>> even a fourth (Eric Niebler's meta). I think it would be wise to have a
>> plan
>> for how we're going to deal with this.
>>
>> Before going further, I'd also like to clear something out. Some people
>> have
>> asked whether "classic" metaprogramming libraries still had their place
>> given that we now have Hana. As the author of Hana, I think the answer is
>> yes. While Hana is (IMHO) easier to use and more powerful, it also has an
>> important shortcoming. Hana is too slow when dealing with very large
>> inputs.
>> This is due to the fact that it can also handle values, which is much
>> heavier than dealing with types only. This can be alleviated to some
>> extent,
>> but the truth is that our execution model (the compiler) simply has to do
>> more work when handling values.
>>
>> Hence, I think Boost does need a modern classic TMP library to handle
>> these
>> cases where a library writer needs to handle gigantic type lists. I think
>> marketing such a library as an advanced tool for library writers would be
>> a
>> service to the overall C++ community, but that's an orthogonal concern.
>>
>> However, Boost needs one such library, not four. I think we can't just do
>> 4
>> reviews and include all the libraries that pass in Boost; that would be a
>> huge disservice to our users, who will be left with the burden of
>> choosing.
>> Heck, if we can't even make our mind, how can they?
>>
>> So, how do we pick? Have we ever been in a similar situation where we have
>> multiple competing libraries solving _exactly_ the same problem?
>>
>> If there were several proposals, we could review all of them together. We
> already did that for the thread/futures proposals.
>
> I believe that some of the things we need to answer are:
> * 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 :( )
> * do we need lazy evaluation?
> * do we need lambdas?
> * do we want a C++11/C++14/C++17 library?
> .... other you can think of.
>

To add to that list, we also need to ask ourselves

* do we need SFINAE friendliness?
* do we want to use pattern matching to extract data from concepts?


> However I see only one official proposal (mp11 - Peter Dimov), even if
> there are other interesting libraries (as Meta, Brigand).
> <http://lists.boost.org/mailman/listinfo.cgi/boost>
>

The formal submission of Metal is just a matter of formality and will
happen in the following days.

Bruno

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

Re: About all these metaprogramming libraries

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

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

This is a metafunction in mp11:

template<class... T> using F = /*...*/;

This is a quoted metafunction:

struct Q
{
    template<class... T> using invoke = /*...*/
};

Since quoted metafunctions are types, you can operate on them (although mp11
doesn't yet provide any built-in means to compose them), but to pass one to
an algorithm, you need

    mp_transform<List, Q::invoke>

instead of just

    mp_transform<List, F>

> I just find it weird to take std::variant as a data type that models type
> list.

The need to operate on the list of variant alternatives is actually pretty
common. Hence std::variant_size (which is just mp_size in mp11),
std::variant_alternative_t (mp_at_c). Similarly std::tuple_size,
std::tuple_element_t. This endless reinvention of the wheel is completely
unnecessary.


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

Re: About all these metaprogramming libraries

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

> On Mar 18, 2017, at 2:32 PM, Louis Dionne via Boost <[hidden email]> wrote:
>
> Dear Boost,
>
> We've seen two metaprogramming libraries ask for a formal review on the list
> recently. I expect a third (Brigand) might join the party soon, and maybe
> even a fourth (Eric Niebler's meta). I think it would be wise to have a plan
> for how we're going to deal with this.
>
> Before going further, I'd also like to clear something out. Some people have
> asked whether "classic" metaprogramming libraries still had their place
> given that we now have Hana.


Of course, there is a place for portability. Hana doesn’t work with gcc 4.8 nor gcc 5 nor MSVC. So if a library would like to support those compilers and utilize a library to handle metaprogramming or heterogeneous sequences, it would be nice to have an alternative modern solution instead of having to continue to use Fusion or MPL.

> As the author of Hana, I think the answer is
> yes. While Hana is (IMHO) easier to use and more powerful, it also has an
> important shortcoming. Hana is too slow when dealing with very large inputs.
> This is due to the fact that it can also handle values, which is much
> heavier than dealing with types only. This can be alleviated to some extent,
> but the truth is that our execution model (the compiler) simply has to do
> more work when handling values.
>
> Hence, I think Boost does need a modern classic TMP library to handle these
> cases where a library writer needs to handle gigantic type lists. I think
> marketing such a library as an advanced tool for library writers would be a
> service to the overall C++ community, but that's an orthogonal concern.
>
> However, Boost needs one such library, not four. I think we can't just do 4
> reviews and include all the libraries that pass in Boost; that would be a
> huge disservice to our users, who will be left with the burden of choosing.
> Heck, if we can't even make our mind, how can they?
>
> So, how do we pick? Have we ever been in a similar situation where we have
> multiple competing libraries solving _exactly_ the same problem?

It would be nice to see better collaboration between authors to build an unifying metaprogramming library, rather than competing against each other. Of course, this can be somewhat difficult as they have different fundamental concepts.

Paul


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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
Paul Fultz II wrote:

> It would be nice to see better collaboration between authors to build an
> unifying metaprogramming library, rather than competing against each
> other. Of course, this can be somewhat difficult as they have different
> fundamental concepts.

As I see it, it's the fundamental concepts competing against each other, and
that's how it should be; how else we'll find out which approach is best?


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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Louis Dionne
On Sat, Mar 18, 2017 at 1:32 PM, Louis Dionne via Boost <
[hidden email]> wrote:

> However, Boost needs one such library, not four. I think we can't just do 4
> reviews and include all the libraries that pass in Boost; that would be a
> huge disservice to our users, who will be left with the burden of choosing.
> Heck, if we can't even make our mind, how can they?
>

These questions are important only under the assumption that the libraries
are interchangeable. I doubt that they are. More likely their authors have
made different design choices, probably even competing design choices.

You can say well, as long one library can do the job of another, we don't
need both. But what if one library is faster in one use case and 10 times
slower in another? What if one library is always slower but can be used in
cases when another library can not?

There are already precedents in Boost of different libraries with
overlapping domains and this is not a problem. Moreover, it is in the
spirit of C++ to allow foor multiple solutions to a single problem, and to
provide just the solution to obscure problems 99% of the C++ programmers
didn't know existed.

Emil

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2017-03-19 12:02, Peter Dimov via Boost wrote:

> Paul Fultz II wrote:
>
>> It would be nice to see better collaboration between authors to build
>> an unifying metaprogramming library, rather than competing against
>> each other. Of course, this can be somewhat difficult as they have
>> different fundamental concepts.
>
> As I see it, it's the fundamental concepts competing against each
> other, and that's how it should be; how else we'll find out which
> approach is best?

Would not that be better to contain the battle among the gurus, the lib
developers. So that they are forced to cooperate, to consider
alternatives, to come up with one best (in their collective opinion)
solution... and leave the user out of it? Otherwise users are forced to
consider 4 solutions, to evaluate those and to decide (potentially
incorrectly) which one to use. As a user I personally do not have the
resources and the knowledge to do that. Taking/choosing a Boost lib I've
always known that there was a lot of effort spent evaluating,
optimizing, improving, etc. the lib. So that I get the best I can get.

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
On Sat, Mar 18, 2017 at 7:48 PM, Vladimir Batov via Boost <
[hidden email]> wrote:

> On 2017-03-19 12:02, Peter Dimov via Boost wrote:
>
>> Paul Fultz II wrote:
>>
>> It would be nice to see better collaboration between authors to build an
>>> unifying metaprogramming library, rather than competing against each other.
>>> Of course, this can be somewhat difficult as they have different
>>> fundamental concepts.
>>>
>>
>> As I see it, it's the fundamental concepts competing against each
>> other, and that's how it should be; how else we'll find out which
>> approach is best?
>>
>
> Would not that be better to contain the battle among the gurus, the lib
> developers. So that they are forced to cooperate, to consider alternatives,
> to come up with one best (in their collective opinion) solution...


There is a big difference between "best" and "best in their collective
opinion".

Also, one library may be best in one thing and suck at something else.

Emil

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/18/17 19:48, Vladimir Batov via Boost wrote:

>
> Would not that be better to contain the battle among the gurus, the lib
> developers. So that they are forced to cooperate, to consider
> alternatives, to come up with one best (in their collective opinion)
> solution... and leave the user out of it? Otherwise users are forced to
> consider 4 solutions, to evaluate those and to decide (potentially
> incorrectly) which one to use. As a user I personally do not have the
> resources and the knowledge to do that. Taking/choosing a Boost lib I've
> always known that there was a lot of effort spent evaluating,
> optimizing, improving, etc. the lib. So that I get the best I can get.
>

Users of these libraries are often library developers. Many of us have
already implemented smallish TMP libraries that we use internally. I
think the Boost community is the right community to review just this
sort of library. Abusing compilers and meta programming rich libraries
is what we are known for (for good or bad).

I expect a combined review to tease out the best design choices and
implementations and may even discover better solutions yet-to-be-discovered.

micahel

--
Michael Caisse
Ciere Consulting
ciere.com

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

Re: About all these metaprogramming libraries

Boost - Dev mailing list
On 2017-03-19 16:42, Michael Caisse via Boost wrote:

> ...
> Users of these libraries are often library developers. Many of us have
> already implemented smallish TMP libraries that we use internally. I
> think the Boost community is the right community to review just this
> sort of library. Abusing compilers and meta programming rich libraries
> is what we are known for (for good or bad).
>
> I expect a combined review to tease out the best design choices and
> implementations and may even discover better solutions
> yet-to-be-discovered.

Probably... If you mean one review of a combined effort... essentially
one (two?) consolidated library... maybe with currently separate libs
made sections/parts of such a combined effort... and duplicate parts
trimmed. All that trimming and negotiations and arguments IMO are better
done backstage... maybe only with some bits and pieces taken to the
list.

Otherwise, if you mean several simultaneous reviews (as they are
currently conducted) of competing functionally-overlapping libs, I
suspect it to result in an overload, a lot of very public fighting and
ultimately a stalemate. As always it is just my opinion. I can be dead
wrong. I often am.



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