Were the changes to MPL splitting it between a core and the rest of MPL supposed to be part of the upcoming release ? Because looking at MPL the 'master' branch is at the previous 1.57 release and there have been quite a number of changes to the 'develop' branch since then, much of it relating to the mpl/core split. The 'develop' regression tests for MPL look pretty green. I would like to get bruno Dutra's fix for MPL arity into the coming release as it has been thoroughly tested on 'develop', but I do not know whether or not all the other MPL 'develop' changes should go in 'master' although I suspect not.
On Sunday 29 March 2015 12:43:05 Edward Diener wrote:
Were the changes to MPL splitting it between a core and the rest of MPL supposed to be part of the upcoming release ?
These changes were rolled back. The split version is still available in my fork: https://github.com/lastique/mpl/tree/modularization 1.58 will contain the monolithic MPL.
Andrey Semashev-2 wrote
On Sunday 29 March 2015 12:43:05 Edward Diener wrote:
Were the changes to MPL splitting it between a core and the rest of MPL supposed to be part of the upcoming release ?
These changes were rolled back. The split version is still available in my fork:
https://github.com/lastique/mpl/tree/modularization
1.58 will contain the monolithic MPL.
I've had occasion to think about this lately. How about this for an idea: Create two new libraries: MetaFunction - would contain the current content of mpl/metafunctions. Typelists - would contain the current content for mpl/sequences without the iterator functionality. Notes: In order to produce a simpler implementation they would not need to be backward compatible with compilers prior to C++11 (or 14 or ...) I don't think they would need the whole sections of integral constant. When the implementation can be done in terms of standard library components or with boost components - standard library components would be preferred. The ultimate goal is that these libraries would be attractive for incorporation into the standard library to complement type_traits and other stuff which has been taken from boost. There is already a lot of "raw material" such as the current mpl, eric's meta, lorises mpl11, and maybe some other stuff. Most of the documentation and tests could almost be transcribed from the current mpl. So it would be an "easy" job. Focus would be not on creating every more powerful functional programming tools and abstractions, but rather as set of simple, understandable tools which would make template meta programming more accessible to those of us who occasionally need it but can't spend a lifetime on it. Call it TMP for the rest of us. I've split it two pieces because I think that these are two orthogonal ideas and it's much easier to do two smaller things than it is one bigger think. I would expect typelists to depend upon metafunctions. I very much like the new names because I think they better clearly describe what they are. Of course current MPL would e around "forever" but it's usage in newer code would be discouraged. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4673891.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mar 29, 2015 2:40 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
I've had occasion to think about this lately. How about this for an idea:
Create two new libraries:
MetaFunction - would contain the current content of mpl/metafunctions.
Typelists - would contain the current content for mpl/sequences without the iterator functionality.
Notes:
In order to produce a simpler implementation they would not need to be backward compatible with compilers prior to C++11 (or 14 or ...)
I don't think they would need the whole sections of integral constant.
When the implementation can be done in terms of standard library components or with boost components - standard library components would be preferred.
The ultimate goal is that these libraries would be attractive for incorporation into the standard library to complement type_traits and other stuff which has been taken from boost.
There is already a lot of "raw material" such as the current mpl, eric's meta, lorises mpl11, and maybe some other stuff. Most of the documentation and tests could almost be transcribed from the current mpl. So it would be an "easy" job.
Focus would be not on creating every more powerful functional programming tools and abstractions, but rather as set of simple, understandable tools which would make template meta programming more accessible to those of us who occasionally need it but can't spend a lifetime on it. Call it TMP for the rest of us.
I've split it two pieces because I think that these are two orthogonal ideas and it's much easier to do two smaller things than it is one bigger think. I would expect typelists to depend upon metafunctions.
I very much like the new names because I think they better clearly describe what they are.
Of course current MPL would e around "forever" but it's usage in newer code would be discouraged.
Robert Ramey
Since the recent discussions regarding MPL and ultimately metaprogramming support in boost, I've engaged in an experimental project, which I believe is close to what you are proposing, I call it MPL2¹. I've been actually inspired by your Library Idea² at Boost Incubator, so my main goal is to start from scratch and provide a drop in replacement for current MPL. I'm following 3 basic premises: 1. Compatibility shall be restricted to "modern compilers", that is, if a compiler can't handle partial template specializations, template template parameters, non type template parameters or other such basic language features, then it can't handle MPL2. 2. It shall be "C++11 aware", that is, it shall not only take full advantage of C++11 additions, especially variadic templates and template aliases, but also fully support it. 3. It shall be able to replace the original MPL on any existing code without modifications, provided it is compiled on a "modern compiler" in the sense of premise #1. Premise #1 addresses concerns that have been raised regarding the maintainability of MPL, which is seriously handicapped by the various tricky workarounds it was forced to ship back in the day in order to guarantee compatibility over a wide range of [nowadays rather obsolete] compilers. MPL2 is expected to be much easier to maintain and improve. Backwards compatibility will be provided by a separate include tree which mimics that of current MPL and effectively translates MPL constructs to MPL2 equivalents. In most cases it should boils down to simply exposing constructs of namespace mpl2 to namespace mpl through the "using" directive, but some room shall be granted for MPL2 to diverge from MPL whenever it proves useful, provided, of course, a proper translation be available at the legacy interface. It should be noted, however, that this legacy interface is expected to "just work" and nothing more, that is, no extra effort will be taken to guarantee performance or widespread compatibility. Hence it should serve simply as a natural bridge for any library, whose developers are willing to update to MPL2 I'm also tentatively maintaining compatibility to C++98/03 despite being advised otherwise by some experienced developers and so far it is going surprisingly well. To accomplish that I came up with a very simple and comprehensible set of macros³ which provide forward compatibility of variadic templates, template aliases and some other C++11 goodies to C++98/03 through what I call "semantic emulation". All that without impairing code clarity or maintainability too much, but that's of course just my opinion. I invite anyone interested to take a look at it (links at the bottom) and perhaps share some thoughts. I must also add that, whenever choices must be made, C++11/14 is never chosen to be handicapped in favor of C++98/03, that is, just like backwards compatibility to MPL, backwards compatibility to older standards should merely work, solely for the sake of minimal portability. Furthermore, I've bought the idea that metafunctions are rather dissociated from containers, so I've split the include tree into two main trunks, currently called core, containing general metafunctions, and sequences for the rest. Now onto some MPL features I plan to improve on MPL2: 1. MPL is rather eager and mostly requires metafunctions to be explicitly instantiated by the "[typename] <>::type" idiom, which I find rather verbose and cumbersome. I do believe, peeking at the code, that this design was more a necessity to maintain compatibility with defective compilers than a planed feature. MPL2, on the other hand should be mostly lazy, that is, for instance, mpl2::pop_front<mpl2::list<int, float> > *is* a list just the same as mpl2::list<float> or mpl2::pop_front<mpl2::list<int, float> >::type. The latter, however, shall add functionality which is also not available at MPL and this brings me to the second improvement. 2. Some "well behaved" containers, such as lists, shall have their type specified in a way that template matching shall be possible, essentially making iterators obsolete, like so: //untested code, please don't be too picky c: template<typename list> struct grand_total; template<typename h, typename... t> struct grand_total<mpl2::list<h, t...> > : mpl2::plus<h, grand_total<typename mpl2::pop_front<mpl2::list<h, t...> >::type> //mpl2::list<t...> works too, of course, but hey, that's just an example {}; template<typename h, typename... t> struct grand_total<mpl2::list<> > : mpl2::int_<0> {}; This, however, obviously requires metafunctions to be explicitly instantiated, as may be noted on the example above, but that just brings us back to what MPL is already. It won't be available for every container though, for it makes it impossible to honor constant time insertion at both ends of bidirectional containers, like MPL::vector<>. Still a great number (majority perhaps?) of use cases, which need only constant time insertion at one end should benefit of it. Finally I must add development is still at the very beginning and the resources available to me, essentially time, is rather scarce, but I'm seriously committed to bringing it about, so please don't give up on me :) Bruno Dutra ¹ https://github.com/brunocodutra/mpl2/tree/core ² http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ ³ https://github.com/brunocodutra/mpl2/tree/core/include/boost/mpl2/core/compa...
Bruno Dutra wrote
Since the recent discussions regarding MPL and ultimately metaprogramming support in boost, I've engaged in an experimental project, which I believe is close to what you are proposing, I call it MPL2¹. I've been actually inspired by your Library Idea² at Boost Incubator, so my main goal is to start from scratch and provide a drop in replacement for current MPL.
Naturally I'm very pleased whenever someone else likes an idea of mine.
I'm following 3 basic premises:
1. Compatibility shall be restricted to "modern compilers", that is, if a compiler can't handle partial template specializations, template template parameters, non type template parameters or other such basic language features, then it can't handle MPL2.
2. It shall be "C++11 aware", that is, it shall not only take full advantage of C++11 additions, especially variadic templates and template aliases, but also fully support it.
3. It shall be able to replace the original MPL on any existing code without modifications, provided it is compiled on a "modern compiler" in the sense of premise #1.
I would formalize this to "mpl2 is only guaranteed to work on compilers which implement C++11 or higher" rather than "modern compilers".
Backwards compatibility will be provided by a separate include tree which mimics that of current MPL and effectively translates MPL constructs to MPL2 equivalents. ...snip...
Those who need backward compatibility can just use the original MPL. I don't think that the person who takes this on should spend any time at all on it. If you must do it - leave for last when you've got nothing else to do.
I'm also tentatively maintaining compatibility to C++98/03 despite being advised otherwise by some experienced developers
Add me to the list of "advanced developers". There is nothing to be gained by this. Focus in the smallest task which will be useful to the most people. If you feel you must address older compilers - do it later when everything else is done.
Furthermore, I've bought the idea that metafunctions are rather dissociated from containers, so I've split the include tree into two main trunks, currently called core, containing general metafunctions, and sequences for the rest.
as I said before. my current thinking is that one should make two separate smaller and simpler libraries: a) metafunctions - depends upon nothing except perhaps the C++11+ standard library b) typelists - depends only metafunctions. Get metafunctions done (including tests and documentation) before moving to to typelists. Or better yet, hope that someone else is inspired by your efforts to take typlists up on their own. This would be ideal from my perspective.
Now onto some MPL features I plan to improve on MPL2:
...snip ...
You're getting way off track here. The problem is: MPL is very large and cumbersome, difficult to understand and maintain, too hard to understand. Fix this problem before you think of going on to other problems! Actually it would be very useful to fix half the problem - metafunctions. Fix this problem before going on to anything else.
Finally I must add development is still at the very beginning and the resources available to me, essentially time, is rather scarce, but I'm seriously committed to bringing it about, so please don't give up on me :)
Follow my advice. Make something large enough to be useful but no larger. Much better to have something people use than something that doesn't get done. The smallest useful subset of MPL is going to be a lot more work than you're currently expecting. Robert Ramey PS, I'm to go update my "suggestion" at http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ to reflect my later thinking on the subject. RR -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4673934.html Sent from the Boost - Dev mailing list archive at Nabble.com.
2015-03-30 21:25 GMT-03:00 Robert Ramey <ramey@rrsd.com>:
I'm following 3 basic premises:
1. Compatibility shall be restricted to "modern compilers", that is, if a compiler can't handle partial template specializations, template template parameters, non type template parameters or other such basic language features, then it can't handle MPL2.
2. It shall be "C++11 aware", that is, it shall not only take full advantage of C++11 additions, especially variadic templates and template aliases, but also fully support it.
3. It shall be able to replace the original MPL on any existing code without modifications, provided it is compiled on a "modern compiler" in the sense of premise #1.
I would formalize this to "mpl2 is only guaranteed to work on compilers which implement C++11 or higher" rather than "modern compilers".
I'm also tentatively maintaining compatibility to C++98/03 despite
being advised otherwise by some experienced developers
Add me to the list of "advanced developers". There is nothing to be gained by this. Focus in the smallest task which will be useful to the most people. If you feel you must address older compilers - do it later when everything else is done.
I do understand it will probably not add much to MPL2, but for some reason I've been reluctant to drop compatibility to C++03, specially now that I've set up this very idiomatic way of writing portable code between standards, I just feel like throwing away so much effort... Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
Backwards compatibility will be provided by a separate include tree which mimics that of current MPL and effectively translates MPL constructs to MPL2 equivalents. ...snip...
Those who need backward compatibility can just use the original MPL. I don't think that the person who takes this on should spend any time at all on it. If you must do it - leave for last when you've got nothing else to do.
Agreed, MPL should always be around, but since it will be mostly a matter of exposing ::mpl2 to ::mpl directly, it shouldn't take too much time. At any rate, more than just a legacy interface, I see it as a "fit for purpose" test, so indeed I plan to leave it for last.
Furthermore, I've bought the idea that metafunctions are rather
dissociated from containers, so I've split the include tree into two main trunks, currently called core, containing general metafunctions, and sequences for the rest.
as I said before. my current thinking is that one should make two separate smaller and simpler libraries:
a) metafunctions - depends upon nothing except perhaps the C++11+ standard library
b) typelists - depends only metafunctions.
Get metafunctions done (including tests and documentation) before moving to to typelists. Or better yet, hope that someone else is inspired by your efforts to take typlists up on their own. This would be ideal from my perspective.
My initial goal was to rewrite MPL from scratch, diverting from it on just some minor aspects, so that any existing code could promptly be updated to use it, hence the name MPL [version] 2. I do agree it should be split into modules, specially with the coming "C++ modules", but I'm not so sure it would be a good idea to create yet not just one, but two other boost libraries, which would basically replicate MPL. At any rate, as long as I stick to this modularized concept, it should be trivial to split it into two libraries of their own right, should it so be desired in the future, so I'll stick to the idea of keeping both halves integrated into a single library, at least for now.
Now onto some MPL features I plan to improve on MPL2:
...snip ...
You're getting way off track here. The problem is:
MPL is very large and cumbersome, difficult to understand and maintain, too hard to understand.
Fix this problem before you think of going on to other problems! Actually it would be very useful to fix half the problem - metafunctions. Fix this problem before going on to anything else.
Granted. What I mean here, is that I already have MPL2 entirely designed in my head and I am confident these two improvements I mentioned will be accomplished the way I've designed it, it is now just a matter of finding time to actually write it and, sure enough, to deal with little caveats I couldn't possibly foresee. I'd like to add I've been using MPL extensively for over a year now on an experimental project¹ I've been carrying out, I have studied its documentation thoroughly, have explored its code in depth seeking to understand its little aspects and even got to issue a couple of pull requests addressing 4 open bug reports, one of which I've actually filed myself, so I do feel confident about bringing MPL2 about. Perhaps I'm just too naive to know it better, time will tell :)
Finally I must add development is still at the very beginning and the resources available to me, essentially time, is rather scarce, but I'm seriously committed to bringing it about, so please don't give up on me :)
Follow my advice. Make something large enough to be useful but no larger. Much better to have something people use than something that doesn't get done. The smallest useful subset of MPL is going to be a lot more work than you're currently expecting.
You are absolutely right. I must admit I tend to enlarge my goals to the point I can't possibly achieve it, but the good news are that I am aware of that. I will follow your advice and try not going astray focusing on unimportant matters, beginning by dropping compatibility to C++98/03. Oh and do let me know when you've updated your suggestion at the Boost Incubator. *Bruno Dutra* ¹https://github.com/brunocodutra/metalog
Bruno Dutra wrote:
Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
I feel obliged to encourage you to not do that. People may maintain that C++03 compatibility doesn't matter, but it still does, to a surprising extent. There is considerable value in MPL2 being a drop-in replacement for MPL1. One might even argue that this is the whole point of it.
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 31 March 2015 22:42 To: boost@lists.boost.org Subject: Re: [boost] MPL and MPL core
Bruno Dutra wrote:
Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
I feel obliged to encourage you to not do that. People may maintain that C++03 compatibility doesn't matter, but it still does, to a surprising extent. There is considerable value in MPL2 being a drop-in replacement for MPL1. One might even argue that this is the whole point of it.
I want to echo this. A lot of the testing across the range of compilers is still C++03. John
Peter Dimov-2 wrote
Bruno Dutra wrote:
Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
I feel obliged to encourage you to not do that. People may maintain that C++03 compatibility doesn't matter, but it still does, to a surprising extent. There is considerable value in MPL2 being a drop-in replacement for MPL1. One might even argue that this is the whole point of it.
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4673987.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On 3/31/2015 4:26 PM, Robert Ramey wrote:
Peter Dimov-2 wrote
Bruno Dutra wrote:
Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
I feel obliged to encourage you to not do that. People may maintain that C++03 compatibility doesn't matter, but it still does, to a surprising extent. There is considerable value in MPL2 being a drop-in replacement for MPL1. One might even argue that this is the whole point of it.
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project?
Which is exactly why I don't see the point in writing an MPL clone. -- Eric Niebler Boost.org http://www.boost.org
Eric Niebler wrote: On 3/31/2015 4:26 PM, Robert Ramey wrote: ...
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project?
Which is exactly why I don't see the point in writing an MPL clone.
There isn't much point in writing a C++11 MPL clone, because the idiomatic way to do metaprogramming in C++11 is different. This is why I'm saying that C++03 support is significant for MPL2.
On 3/31/2015 7:43 PM, Peter Dimov wrote:
Eric Niebler wrote:
On 3/31/2015 4:26 PM, Robert Ramey wrote: ...
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project?
Which is exactly why I don't see the point in writing an MPL clone.
There isn't much point in writing a C++11 MPL clone, because the idiomatic way to do metaprogramming in C++11 is different.
If there is an idiomatic way to do metaprogramming in C++11, I'm sure I don't know what it is. But yeah, it's probably not the MPL.
This is why I'm saying that C++03 support is significant for MPL2.
Robert's question stands though. What is the point of a drop-in MPL replacement implemented for C++03 compilers? We already have that. -- Eric Niebler Boost.org http://www.boost.org
2015-04-01 0:00 GMT-03:00 Eric Niebler <eniebler@boost.org>:
On 3/31/2015 7:43 PM, Peter Dimov wrote:
Eric Niebler wrote:
On 3/31/2015 4:26 PM, Robert Ramey wrote: ...
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project?
Which is exactly why I don't see the point in writing an MPL clone.
There isn't much point in writing a C++11 MPL clone, because the idiomatic way to do metaprogramming in C++11 is different.
If there is an idiomatic way to do metaprogramming in C++11, I'm sure I don't know what it is. But yeah, it's probably not the MPL.
I was about to say the very same thing. I keep being told MPL is old fashioned, but, to be honest, so far I've failed to see what the "C++11 way" of metaprogramming is. 2015-04-01 0:16 GMT-03:00 Peter Dimov <lists@pdimov.com>:
Eric Niebler wrote:
Robert's question stands though. What is the point of a drop-in MPL
replacement implemented for C++03 compilers? We already have that.
What we have is unmaintained and, dare I say, unmaintainable, because it targets not C++03, but C++95.
Exactly, that is precisely the main motivation behind my efforts on MPL2, I find it unbearable that such a core library as MPL be left unmaintaned. At the beginning I was in favor of some serious overhauling of it and even started a thread on this matter about a month ago, but that was only till I dug deeper into it and realized how impracticable that was. That's when I decided to start from scratch, focus on modern compilers and ultimately provide a drop in replacement for MPL. I was then convinced backwards compatibility to C++98 could be easily maintained within reasonable use of macros and without too much impairment to code maintainability. To be honest, I still think it is fairly doable, C++98 is nothing compared to the advanced black magic MPL currently ships to target "C++95" as Peter says, but Robert managed to convince me there's little to gain from it. See, whenever C++03 is required, MPL is still there and does the job, period. For modern usage, MPL2 sure would come handy, it would be guaranteed to be maintained and most certainly would be able provide much more advanced features than good old MPL could ever be dreamed to provide. Now please bear in mind I said that there's "little" gain from backwards compatibility to C++98, I didn't say there's none. Sure there's plenty of setups out there that would do great use of MPL2 on a C++03 environment, and I'm glad I'm not the only one who believes so, but I'm just not so convinced anymore it is worth spending too much effort on it while there's still a much more important matter to be addressed, which is MPL's current maintainability status. I haven't given up on backwards compatibility to older standards, I've just postponed it to a more convenient time. *Bruno C. O. Dutra*
----- Original Message -----
From: "Bruno Dutra" <brunocodutra@gmail.com>
If there is an idiomatic way to do metaprogramming in C++11, I'm sure I don't know what it is. But yeah, it's probably not the MPL.
I was about to say the very same thing. I keep being told MPL is old fashioned, but, to be honest, so far I've failed to see what the "C++11 way" of metaprogramming is.
2c: This is exactly why modern non-legacy-constrained C++14 metaprogramming libraries are needed: to discover, organize, and formalize that unknown. Regards, Paul Mensonides
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of pmenso57@comcast.net Sent: 01 April 2015 05:02 To: boost@lists.boost.org Subject: Re: [boost] MPL and MPL core
----- Original Message -----
From: "Bruno Dutra" <brunocodutra@gmail.com>
If there is an idiomatic way to do metaprogramming in C++11, I'm sure I don't know what it is. But yeah, it's probably not the MPL.
I was about to say the very same thing. I keep being told MPL is old fashioned, but, to be honest, so far I've failed to see what the "C++11 way" of metaprogramming is.
2c: This is exactly why modern non-legacy-constrained C++14 metaprogramming libraries are needed: to discover, organize, and formalize that unknown.
+1 Since we have MPL1 which works for C++03, there should be no limitations on compile features used for MPL2. MPL2 should try to leap forward as far as possible. (If it turns out that C++11++ features are not useful to do MPLy tasks, that is also useful info). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
MPL2 sure would come handy, it would be guaranteed to be maintained and most certainly would be able provide much more advanced features than good old MPL could ever be dreamed to provide.
I would counsel against expanding the scope beyond the minimum. You can always to that later. The number one problem with making a Boost library (or any library no tied to some specific application) is that the developer becomes so enthralled with his work that he makes it better before it makes it "done" (including tests, documentation etc.) I suggest: a) task one - make metafuction library. This library would include all the metafunctions in MPL1 - and nothing else. b) submit the above for review. That would be a good time to think about other stuff. a larger project that doesn't get finished much less interesting for us than a smaller project that is actually done. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4674000.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On Apr 1, 2015 1:16 AM, "Robert Ramey" <ramey@rrsd.com> wrote:
MPL2 sure would come handy, it would be guaranteed to be maintained and most certainly would be able provide much more advanced features than good old MPL could ever be dreamed to provide.
I would counsel against expanding the scope beyond the minimum. You can always to that later. The number one problem with making a Boost library (or any library no tied to some specific application) is that the developer becomes so enthralled with his work that he makes it better before it makes it "done" (including tests, documentation etc.).
a larger project that doesn't get finished much less interesting for us than a smaller project that is actually done.
Robert Ramey
Absolutely. When I speak of enhancements I merely foresee that if MPL2 proves itself useful and be thus embraced by the community, then it will be most natural for it to be pushed forward. Aside from a couple of improvements that should arise naturally from a well thought design, initially I plan to attain just to MPL's original scope and focus on getting it done. On Apr 1, 2015 7:00 AM, "Paul A. Bristow" <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of
Sent: 01 April 2015 05:02 To: boost@lists.boost.org Subject: Re: [boost] MPL and MPL core
----- Original Message -----
From: "Bruno Dutra" <brunocodutra@gmail.com>
If there is an idiomatic way to do metaprogramming in C++11, I'm sure I don't know what it is. But yeah, it's probably not the MPL.
I was about to say the very same thing. I keep being told MPL is old fashioned, but, to be honest, so far I've failed to see what the "C++11 way" of metaprogramming is.
2c: This is exactly why modern non-legacy-constrained C++14
to
discover, organize, and formalize that unknown.
+1
Since we have MPL1 which works for C++03, there should be no limitations on compile features used for MPL2.
MPL2 should try to leap forward as far as possible.
(If it turns out that C++11++ features are not useful to do MPLy tasks,
pmenso57@comcast.net metaprogramming libraries are needed: that is also useful info).
Paul
The thoughts you all have been sharing with me have been helping me better shape what specific necessities MPL2 is expected to satisfy. I'm naturally glad to realize that there's still so much interest in MPL/MPL2 and that every time this topic is raised so many people join the discussion to express their opinions. Bruno Dutra
Eric Niebler <eniebler <at> boost.org> writes:
On 3/31/2015 4:26 PM, Robert Ramey wrote:
Peter Dimov-2 wrote
Bruno Dutra wrote:
Oh well, I guess you convinced me to at least postpone it. I'll branch off from what I've got so far and strip every C++03 out of it.
I feel obliged to encourage you to not do that. People may maintain that C++03 compatibility doesn't matter, but it still does, to a surprising extent. There is considerable value in MPL2 being a drop-in replacement for MPL1. One might even argue that this is the whole point of it.
But don't we already have MPL1 for that? If one has to make MPL2 more complex to support MPL1 - wouldn't that defeat the whole point of the project?
Which is exactly why I don't see the point in writing an MPL clone.
I second this. Furthermore, I'll admit to being slightly fed up with those attempts to get a new MPL. I feel like we've been there and done that (I did it, at least). Here's a timeline of my last 3 programming years (I'm literally browsing my commit history on GitHub): August 2012: I start working on a drop-in replacement for the MPL with C++11 techniques. This project has __precisely__ the same goal as the MPL2 project. November 2012: I stop working on the project to focus on another unrelated project. June 2013: I start working on the project again. At some point, I am so close to being a drop-in replacement for the MPL that I document difference with the MPL's API. See for example [1]. December 2013: I realize that we could have something much more powerful than the current MPL by embracing lazy metafunctions. I start diverging from the MPL in rather serious ways. May 2014: I present the state of my work at C++Now. At the end of my slides, I present a potential way of metaprogramming using function call syntax, as a pure curiosity. This had been explored before by Zach Laine and Matt Calabrese in a slightly different way. Speaking with other attendees, we push the concept forward and I lay down a prototype for what is now Hana. At that point, I don't even think I knew it would be powerful enough to replace Fusion. I just thought it was a nice way of doing type-level computations. Summer 2014: Joel Falcou (my GSoC mentor) and I determine that the function call syntax is the way to go, and so I work on Hana instead of MPL11 (as was planned) during the GSoC of 2014. after GSoC and up to now: I continue working on Hana, improving it, polishing it and testing it. I am confronted to new metaprogramming problems and I am consistently able to solve them elegantly with Hana, which comforts me into thinking that this really is _the_ way. Apart from this, there are several other metaprogramming projects that try to solve the "metaprogramming problem" for C++, like Eric's Meta and Manu's Turbo. Both of them are pretty different from the MPL, for reasons the authors could probably justify. This wall of text (sorry) brings us to the following question: Why would you want an MPL replacement when you could have much better? If you're going to go for C++11/14 anyway, why in heaven would you want to stick to the MPL? I could understand a 100% backward compatible C++03 overhaul of the current MPL, which would give you 1. Improved compile-time and error messages in __existing__ code 2. Easier to maintain MPL codebase However, I do not see a justification for sticking with the MPL when writing new code. Anyway, if you (Bruno) still want to go down this path, which has been beaten, please at least do not start from scratch. I would suggest you fork the MPL11 around the commit at [2], which is an almost complete backward-compatible implementation of the MPL for C++11. It even has iterators and all that stuff. You can contact me off-list regarding this if you want. Regards, Louis [1]: http://goo.gl/ojkuzW [2]: http://goo.gl/aQD8Wc
2015-04-01 10:13 GMT-03:00, Louis Dionne <ldionne.2@gmail.com>: [...]
Why would you want an MPL replacement when you could have much better?
Well, why would you want much better if you can have much simpler? :)
If you're going to go for C++11/14 anyway, why in heaven would you want to stick to the MPL?
There seems to be a misconception that MPL is utterly outdated and old fashioned, but I beg to differ. I find myself increasingly fond of its design and I particularly like how well it mimics STL. In my opinion, that is precisely one of its greatest strengths.
I could understand a 100% backward compatible C++03 overhaul of the current MPL, which would give you 1. Improved compile-time and error messages in __existing__ code 2. Easier to maintain MPL codebase
These were exactly the arguments which initially motivated me to start MPL2. I had failed to realize then, however, that existing code should usually compile just fine on modern compilers too and, therefore, could certainly benefit of MPL2 even if it were to drop compatibility to C++03. See, I don't think developers usually chose to enforce C++03, I mean, they might very well prefer coding in a more traditional way and not use C++11 features, but that does not require support for newer features to be strictly disabled on modern compilers. Let us not forget C++11 is backwards compatible.
However, I do not see a justification for sticking with the MPL when writing new code. Anyway, if you (Bruno) still want to go down this path, which has been beaten, please at least do not start from scratch. I would suggest you fork the MPL11 around the commit at [2], which is an almost complete backward-compatible implementation of the MPL for C++11. It even has iterators and all that stuff. You can contact me off-list regarding this if you want.
Regards, Louis
As I said before, and I think at least Robert has expressed a very similar view of this matter, sometimes the user just needs basic type computations and would rather not spend time developing it her/himself. For such use cases I believe MPL excels and might thus be prefferred. At any rate, I don't think MPL would ever compete with Fusion or Hana, simply because they all serve for similar, but definitely different purposes. I'm also aware you had gone down a very similar path before you decided to go for something bigger and I'm sure you had justified motives to do so. However the problem persists, MPL is still left unmaintained and I'd like to do something about it. All this recurrent discussions just contribute to strengthen my beliefs that there's indeed something to gain from a rewriting of MPL and I'll certainly continue. I really appreciate your help and I'll surely take a look at MPL11, there's definitelly a lot that could be reused. In fact I'm still to come up with a decent design for iterators so I'm certainly interested in taking a look at how you've done it. -- *Bruno C. O. Dutra*
Bruno Dutra wrote
2015-04-01 10:13 GMT-03:00, Louis Dionne <
ldionne.2@
>: [...]
Why would you want an MPL replacement when you could have much better?
Well, why would you want much better if you can have much simpler? :)
If you're going to go for C++11/14 anyway, why in heaven would you want to stick to the MPL?
There seems to be a misconception that MPL is utterly outdated and old fashioned, but I beg to differ. I find myself increasingly fond of its design and I particularly like how well it mimics STL. In my opinion, that is precisely one of its greatest strengths.
I don't think that MPL can be seen as "simple". Neither considering its idioms, related mostly to old C++ features. typename ::type, iterator based interface, etc; which make the code far more obfuscated than Meta or Hana. The point of getting the effort to write a new metaprogramming library for Boost is to study how C++11/14, i.e. new features and idioms, can aid when metaprogramming. Getting stuck on old idioms is not a good idea. Want backwards compatibility? Then just install Boost <= 1.57.0. Is that easy. Anyway, I'm agree with Louis that most metaprogramming libraries that have come after C++11 look at tmp in a very different way. The STL-like interface is not a plus point for MPL at all. The STL is not designed for functional programming, and like it or not, TMP is functional. Also comes with exactly the same composability problem the STL has with its iterator based interface. Of course there are workarounds like metafunction classes, but they are just that, workarounds. Iterators make sense with head:tail typelists, but have no place on modern metaprogramming and variadic templates. So, what we are trying to achieve here? Reading the full thread, it's clear that three main bullets raise out: - Simple - Modern - Backwards compatible (Again, just install previous MPL versions) For simple metaprogramming, I think Eric's Meta does the job. Eager, simple, ready for common metaprogramming problems. Modern/reinvent the paradigm? Hana looks nice, throwing away almost all the syntax idiosyncrasies of TMP. I'm trying the same with Turbo, but my goal is to write Haskell-like code (Still on it, Turbo does not currently do that entirely). I think we should accept that TMP is functional, and get the best of the fp world. My long-term goal is to port almost all the Haskell prelude to tmp, in the same sense of FTL but at compile-time. Summing up: MPL style is not the best for modern TMP. If you still keep thinking on a new MPL on the same way of the old one, then the separation between a metafunctions library and a typelists library is the right thing to do. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4674036.html Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (11)
-
Andrey Semashev -
Bruno Dutra -
Edward Diener -
Eric Niebler -
Fletcher, John P -
Louis Dionne -
Manu343726 -
Paul A. Bristow -
Peter Dimov -
pmenso57＠comcast.net -
Robert Ramey