Request for endorsements for mp11
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost? As a reminder, mp11 is a simple C++11 metaprogramming library, available at https://github.com/pdimov/mp11/ CSS-less documentation can be viewed at https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
To Ron and Boost: I endorse mp11. Glen On Mon, May 22, 2017 at 7:43 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
As a reminder, mp11 is a simple C++11 metaprogramming library, available at
https://github.com/pdimov/mp11/
CSS-less documentation can be viewed at
https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, May 22, 2017 at 4:43 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
At first I thought "great, another metaprogramming library I won't understand." But then I read this: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html Beautiful article, thank you so much for putting it together. It was easy to read, starting with a simple appealing example and then building on it stepwise to accomplish progressively larger and more impressive tasks. Tricks are explained plainly, I've already learned a technique or two. I especially like the tenfold optimization on instantiations. It certainly looks useful for Boost, and I appreciate that it is C++11 which means I can use it.
On Mon, May 22, 2017 at 1:43 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
[...] mp11 is a simple C++11 metaprogramming library, [...] https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
From reading the Boost ML, it seems that one of the major difference between the "competing" modern meta-programming libraries is around SFINAE [1], yet I found a single mention in the doc for a subtle use of mp_defer. For non-experts like me, it might be useful to highlight more of the design rational for going with "simpler and eager-by-default" design (if I got that right) while still allowing SFINAE via mp_defer, versus other SFINAE-first approaches?
I just remembered from past long threads on this subject that it wasn't quite clear cut, and would appreciate maybe a few sentences to summarize the problem and explain which approach mp11 took and why? For non-expert preferably. Unless I missed it in the doc. And perhaps also contrast proposed mp11 with Boost.Hana, and even classical Boost.MPL? Thanks, --DD [1] http://en.cppreference.com/w/cpp/language/sfinae
Dominique Devienne wrote:
From reading the Boost ML, it seems that one of the major difference between the "competing" modern meta-programming libraries is around SFINAE [1], yet I found a single mention in the doc for a subtle use of mp_defer. For non-experts like me, it might be useful to highlight more of the design rational for going with "simpler and eager-by-default" design (if I got that right) while still allowing SFINAE via mp_defer, versus other SFINAE-first approaches?
mp_defer is not an alternative to SFINAE-friendly algorithms. It's a tool that can be used to implement SFINAE-friendly traits. The standard library, for example, occasionally says "this trait should have a nested type equivalent to that if valid, otherwise should have no nested type." This is what mp_defer implements; given a SFINAE-friendly template alias, it gives you the trait. Providing mp_defer is not a replacement to algorithms being SFINAE-friendly. Ideally, they should be, although to what degree is still a subject of active discussion. I haven't made them so because it's kind of hard; compilers, even latest ones, often do not implement SFINAE properly in corner cases, to say nothing about their earlier versions. Proper, all the way, SFINAE friendliness is quite a but of work, and is often unnecessary in practice. For example, mp_transform<F, L1, L2> can fail if 1. L1 or L2 is not a list; 2. L1 and L2 are not of the same size; 3. F<T1, T2> for some T1/T2 from L1/L2 fails. I had implemented (1) in my original iteration, now I'm at (2), but haven't got (3). This is not a design decision; it's just what the implementation currently does. It's also not a property of the eager by default design; eager by default can still SFINAE.
Yes, I endorse it. Read the articles long time ago, mp11 implements that. I guess it's not gonna get simpler than that. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On 5/22/17 4:43 AM, Peter Dimov via Boost wrote:
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
As a reminder, mp11 is a simple C++11 metaprogramming library, available at
https://github.com/pdimov/mp11/
CSS-less documentation can be viewed at
https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I read this some time ago - and think it's great. At the same time there is at least one other proposal which overlaps. And then there is Hana. And truth is, I can't understand all the comparative advantages/disadvantages of the various proposals. I would hope that we find a way to discuss them as a set rather than being required to approve/disapprove one a time. This latter would mean that the selection of the "best" proposal would be affected by the order of evaluation - not a good thing. I realize that there is a big risk that this could/would likely turn into a rhetorical fiasco which would leave us worse off, but still ...
Robert Ramey wrote:
And then there is Hana.
There'll always be Hana, I suppose. mp11 is not quite a competitor to Hana. True, they both do metaprogramming. But mp11 is rather a replacement for the myriads of hand-rolled type-based metaprogramming primitives scattered all over people's code; it's like a collection of these same primitives, but done coherently and with an unified naming convention. (And with, I suppose, proper-ish documentation and a test suite.) It pains me each time I see the same mp_wheel being reinvented, and each time the standard library acquires an ad-hoc, arbitrarily named, metaprogramming primitive. This has to end.
On 5/22/17 7:56 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
And then there is Hana.
There'll always be Hana, I suppose.
mp11 is not quite a competitor to Hana. True, they both do metaprogramming. But mp11 is rather a replacement for the myriads of hand-rolled type-based metaprogramming primitives scattered all over people's code; it's like a collection of these same primitives, but done coherently and with an unified naming convention. (And with, I suppose, proper-ish documentation and a test suite.)
It pains me each time I see the same mp_wheel being reinvented, and each time the standard library acquires an ad-hoc, arbitrarily named, metaprogramming primitive. This has to end.
Right - I mean to suggest a strategy to achieve that. Robert Ramey.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
El 22/05/2017 a las 13:43, Peter Dimov via Boost escribió:
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
I endorse mp11. In my view, mp11 serves as a low entry barrier replacement for Boost.MPL taking advantage of C++11 and without the conceptual complexities of Boost.Hana (which BTW requires C++14). Boost.Hana is a terrific library, but there's definitely a place for mp11 for those of us metaprogramming the old MPL-way. When I really want extra power and expressivity, I'll go for Hana. Joaquín M López Muñoz
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
As a reminder, mp11 is a simple C++11 metaprogramming library, available at
https://github.com/pdimov/mp11/
CSS-less documentation can be viewed at
https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html I endorse mp11 even if don't share all the design decisions. I believe
Le 22/05/2017 à 13:43, Peter Dimov via Boost a écrit : that there is a place for other meta-programming libraries in Boost, mp11 would be a good candidate. The library that users will find more useful will survive, and the others will dead. We need more competition in Boost. It would be interesting however to see what all of them have in common (if there is something). Some kind of interaction between the MetaProgramming libraries will be welcome. If there are other MetaProgramming libraries ready for submission it will be extra to have a shared review. I suggest the authors of these MetaProgramming libraries, wanting a better MetaProgramming library in Boost, to contact each other (copying the review wizards) in order have a common review. I suspect that from the 5 MetaProgramming libraries (mp11, metal, meta, brigand and kvasir) that are circulating, not all the authors want his library in Boost, so the problem will be reduced. Best, Vicente
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
As a reminder, mp11 is a simple C++11 metaprogramming library, available at
CSS-less documentation can be viewed at
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frawgit.com%2Fpdimov%2Fmp11%2Fmaster%2Fdoc%2Fhtml%2Fmp11.html&data=02%7C01%7CJ.P.Fletcher%40aston.ac.uk%7C11c5bfcaef474339b5c608d4a1431d4f%7Ca085950c4c2544d5945ab852fa44a221%7C0%7C0%7C636310757008692449&sdata=gjyIPl5hUpVJtQRDdDKoXL47sAHCdJA6T2moC8%2BXQn0%3D&reserved=0 I endorse mp11 even if don't share all the design decisions. I believe
As a result of this request I am having a look at mp11. The documentation talks about C++11. The example in the documentation on this page https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html contains std::common_type_t and other things which are in C++14 and not C++11. Please can the documentation be modified to be clear on what is usable in C++11. Thank you John Fletcher ________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Vicente J. Botet Escriba via Boost [boost@lists.boost.org] Sent: 22 May 2017 19:47 To: boost@lists.boost.org Cc: Vicente J. Botet Escriba; Peter Dimov Subject: Re: [boost] Request for endorsements for mp11 Le 22/05/2017 à 13:43, Peter Dimov via Boost a écrit : that there is a place for other meta-programming libraries in Boost, mp11 would be a good candidate. The library that users will find more useful will survive, and the others will dead. We need more competition in Boost. It would be interesting however to see what all of them have in common (if there is something). Some kind of interaction between the MetaProgramming libraries will be welcome. If there are other MetaProgramming libraries ready for submission it will be extra to have a shared review. I suggest the authors of these MetaProgramming libraries, wanting a better MetaProgramming library in Boost, to contact each other (copying the review wizards) in order have a common review. I suspect that from the 5 MetaProgramming libraries (mp11, metal, meta, brigand and kvasir) that are circulating, not all the authors want his library in Boost, so the problem will be reduced. Best, Vicente _______________________________________________ Unsubscribe & other changes: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=02%7C01%7CJ.P.Fletcher%40aston.ac.uk%7C11c5bfcaef474339b5c608d4a1431d4f%7Ca085950c4c2544d5945ab852fa44a221%7C0%7C0%7C636310757008702457&sdata=BFY%2Bvcf7AJad7XkMEYm3rRx8Yl8LLH26GJXXQkON5xE%3D&reserved=0
Le 22/05/2017 à 21:47, Fletcher, John P via Boost a écrit :
As a result of this request I am having a look at mp11. The documentation talks about C++11.
The example in the documentation on this page https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
contains std::common_type_t and other things which are in C++14 and not C++11.
I believe the examples could use C++14 as far as the source of the library is written in portable C++11. I believe that we should have all the _t traits defined in Boost for C++11 and all the _v varaible aliases for C++14. What other things have you found in the examples? Best, Vicente
Fletcher, John P wrote:
As a result of this request I am having a look at mp11. The documentation talks about C++11.
The example in the documentation on this page https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html
contains std::common_type_t and other things which are in C++14 and not C++11.
Please can the documentation be modified to be clear on what is usable in C++11.
Everything in the library is usable in (and being tested on) C++11, but the examples use a few C++14 features here and there, mostly the _t variants of the standard type traits and polymorphic lambdas. Now that we have _t traits in Boost.TypeTraits (on the develop branch for now), I could in principle make the examples use them instead, although they're clearer as is.
Vicente J. Botet Escriba wrote:
I endorse mp11 even if don't share all the design decisions.
Vicente, since last time, I made some changes that moved the library in a direction you might like. Namely, I added mp_bind, mp_bind_front and mp_bind_back (and removed bind_front functionality from mp_quote), and I'm gradually adding _q "overloads" that take quoted metafunctions.
Le 22/05/2017 à 20:47, Vicente J. Botet Escriba via Boost a écrit :
Would anyone be so kind as to formally endorse mp11 as a candidate for Boost?
As a reminder, mp11 is a simple C++11 metaprogramming library, available at
https://github.com/pdimov/mp11/
CSS-less documentation can be viewed at
https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html I endorse mp11 even if don't share all the design decisions. I believe
Le 22/05/2017 à 13:43, Peter Dimov via Boost a écrit : that there is a place for other meta-programming libraries in Boost, mp11 would be a good candidate. The library that users will find more useful will survive, and the others will dead. We need more competition in Boost.
It would be interesting however to see what all of them have in common (if there is something). Some kind of interaction between the MetaProgramming libraries will be welcome.
If there are other MetaProgramming libraries ready for submission it will be extra to have a shared review. I suggest the authors of these MetaProgramming libraries, wanting a better MetaProgramming library in Boost, to contact each other (copying the review wizards) in order have a common review. I suspect that from the 5 MetaProgramming libraries (mp11, metal, meta, brigand and kvasir) that are circulating, not all the authors want his library in Boost, so the problem will be reduced.
Vicente, since last time, I made some changes that moved the library in a direction you might like. Namely, I added mp_bind, mp_bind_front and mp_bind_back (and removed bind_front functionality from mp_quote), and I'm gradually adding _q "overloads" that take quoted metafunctions.
Hi Peter. I don't know why I'm not receiving most of the mails you are sending lately. This concerns also other threads. Thanks for the info. I'll take a look. Vicente
participants (9)
-
degski -
Dominique Devienne -
Fletcher, John P -
Glen Fernandes -
Joaquin M López Muñoz -
Peter Dimov -
Robert Ramey -
Vicente J. Botet Escriba -
Vinnie Falco