[MPL lite or MPL 2] A modest proposal
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/> -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 03/04/2015 03:17 PM, Robert Ramey wrote:
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>
I think that building an MPL replacement without sequences would be an exercise in futility. The bulk of my MPL usage is handling MPL sequences. In Christ, Steven Watanabe
On 3/4/2015 3:04 PM, Steven Watanabe wrote:
On 03/04/2015 03:17 PM, Robert Ramey wrote:
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>
I think that building an MPL replacement without sequences would be an exercise in futility. The bulk of my MPL usage is handling MPL sequences.
Agreed. Also, I don't think the world needs a drop-in replacement for the MPL. The language has changed and so has our thinking. It least, it's not clear to me that iterators make sense in a metaprogramming environment. -- Eric Niebler Boost.org http://www.boost.org
2015-03-04 19:17 GMT-03:00 Robert Ramey <ramey@rrsd.com>:
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>
To be honest I think implementing sequences is the easiest part. All of the various concepts may straightforwardly be derived from an efficient "random access concept" implementation which takes advantage of variadic templates and decltype(). My only concern are iteretors, but they to, I believe, shouldn't be that hard to derive from a "random access concept". I've actually been drafting exactly what the proposal asks for, I'll let you know if I ever get somewhere. *Bruno C. O. Dutra*
Bruno Dutra wrote
To be honest I think implementing sequences is the easiest part.
Speaking for myself, I don't find this easy at all. It always consumes much more time than I imagine when I start out. That's why my suggestion is to create an initial milestone. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
Eric Niebler-4 wrote
On 3/4/2015 3:04 PM, Steven Watanabe wrote:
I think that building an MPL replacement without sequences would be an exercise in futility. The bulk of my MPL usage is handling MPL sequences.
Agreed. Also, I don't think the world needs a drop-in replacement for the MPL.
I'm not convinced either - but it's better than trying to fix up MPL using modern C++ to make it easier to maintain.
The language has changed and so has our thinking. It least, it's not clear to me that iterators make sense in a metaprogramming environment.
I would agree to that. I would also expect that sequences should be separate from metafunctions. I'm not unhappy with leaving MPL as it is. But there have been concerns that it's hard to maintain and a lot more complicated than it has to be given the facilities of modern compilers. I also believe that if meta-functions were separated, they could eventually be considered for inclusion to the standard. To my mind, it doesn't make a whole lot of sense to have type_traits without metafunctions. Note that I'm suggesting that the MPL be replaced but rather part should be rebuilt as a new library - maybe it would better to call it meta-function library. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
Steven Watanabe-4 wrote
AMDG
On 03/04/2015 03:17 PM, Robert Ramey wrote:
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>;
I think that building an MPL replacement without sequences would be an exercise in futility. The bulk of my MPL usage is handling MPL sequences.
I don't think that's typical. I did a search of the serialization library and found only meta-functions. I understand the units library, fusion and variant might weil use the sequences. Note that I'm not really thinking of replacing the current MPL. Rather those who've expressed concern about the current implementation have the option of creating and MPL lite which would address the concerns they've raised. The classic MPL would stay around until it's no longer needed - which might never occur. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 04 March 2015 22:18 To: boost@lists.boost.org Subject: [boost] [MPL lite or MPL 2] A modest proposal
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>
FWIW - Sounds sensible. But I agree that sequences are probably rather useful. To make the task as un-impossible as possible, the most recent compilers and new features should be encouraged? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Thu, Mar 5, 2015 at 1:17 AM, Robert Ramey <ramey@rrsd.com> wrote:
I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/>
This sounds very similar to the MPL and MPL.Core separation [1]. I didn't drop workarounds for old compilers (except for one for Borland), but MPL.Core seems to be close to what you list as MPL lite. I think it is quite possible to drop the compatibility cruft from MPL.Core, although I'm not sure how useful that would be. Others have stated that newer language features can be used but require a reimplementation. That's probably true, although I'm quite happy with the current MPL.Core interface (note - not the iterators stuff, which is not part of MPL.Core). [1] https://github.com/lastique/mpl/tree/modularization
Andrey Semashev-2 wrote
This sounds very similar to the MPL and MPL.Core separation [1]. I didn't drop workarounds for old compilers (except for one for Borland), but MPL.Core seems to be close to what you list as MPL lite. I think it is quite possible to drop the compatibility cruft from MPL.Core, although I'm not sure how useful that would be.
That's what (part of) the discussion has been about. Since you're doing the work and taking responsibility for it, you get to decide which is the easiest/best way to do it.
Others have stated that newer language features can be used but require a reimplementation. That's probably true, although I'm quite happy with the current MPL.Core interface
I would like to make a clear distinction between interface and implementation. MPL Core/Lite MUST support the the current interface. If convenient and/or useful, the interface could be expanded (but then you'd have to update the documentation and tests). But the implementation could take advantage of modern C++ and wouldn't be required to be compatible with any compiler which doesn't support C++11+. So presumable this would be much easier than the current MPL
(note - not the iterators stuff, which is not part of MPL.Core).
My view is that the concept of type lists (sequences) is orthogonal to metafunctions. I think dividing MPL into two separate libraries would leave us with something easier to understand and maintain and would also reduce dependencies. So instead of having one very large complex library for which we're unable to find a maintainer, we'd have two large complex libraries for which we'd be unable to find maintainers. Is that progress? I think so. Also, I think that we could evolve to this solution without being overly disruptive. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
2015-03-05 12:04 GMT-03:00, Robert Ramey <ramey@rrsd.com>:
But the implementation could take advantage of modern C++ and wouldn't be required to be compatible with any compiler which doesn't support C++11+. So presumable this would be much easier than the current MPL
I do understand dropping support to ancient defective compilers, but why should it also deny support to older language standards on compilers that do comply with them? No doubt it should benefit from post C++11 features, notably variadic templates, but I don't see why it shouldn't emulate variadics on C++98/03 setups, just like it already does today. Please note the difference between old deffective implementations from valid implementations of older standards. I share the point of view of some others here who advocate that, were MPL to be written today, would it probably be designed in an entirely new way, possibly similarly to the way Hana and Meta were designed. This way, IMO there seems to be little sense in rewriting MPL exclusively for compilers that support C++11. -- *Bruno C. O. Dutra*
AMDG On 03/05/2015 11:43 AM, Bruno Dutra wrote:
I do understand dropping support to ancient defective compilers, but why should it also deny support to older language standards on compilers that do comply with them? No doubt it should benefit from post C++11 features, notably variadic templates, but I don't see why it shouldn't emulate variadics on C++98/03 setups, just like it already does today. Please note the difference between old deffective implementations from valid implementations of older standards.
I think you underestimate just how painful it is to emulate variadics in C++03. In Christ, Steven Watanabe
Steven Watanabe <watanabesj <at> gmail.com> writes:
AMDG
On 03/05/2015 11:43 AM, Bruno Dutra wrote:
I do understand dropping support to ancient defective compilers, but why should it also deny support to older language standards on compilers that do comply with them? No doubt it should benefit from post C++11 features, notably variadic templates, but I don't see why it shouldn't emulate variadics on C++98/03 setups, just like it already does today. Please note the difference between old deffective implementations from valid implementations of older standards.
I think you underestimate just how painful it is to emulate variadics in C++03.
+1 It's a _lot_ of work, and you end up with something that's only marginally more readable than the current MPL. Louis
2015-03-05 15:57 GMT-03:00, Steven Watanabe <watanabesj@gmail.com>:
I think you underestimate just how painful it is to emulate variadics in C++03.
Oh, sadly I know very well how painful it is. I've been playing with a metaprogramming library for over a year now and the sole reason why I'm still so far away from reaching my intended goal is precisely the emulation of variadics, which often forces me to abuse the preprocessor and, hence, to deal with the mess it entails. Please don't get me wrong, I don't mean to diminish the effort, I just don't see any reason to pursue an overhaul of MPL, if it were to deny support to C++98/03. But that's just my humble opinion ofc. -- *Bruno C. O. Dutra*
Bruno Dutra wrote
2015-03-05 12:04 GMT-03:00, Robert Ramey <
ramey@
>:
But the implementation could take advantage of modern C++ and wouldn't be required to be compatible with any compiler which doesn't support C++11+. So presumable this would be much easier than the current MPL
I do understand dropping support to ancient defective compilers, but why should it also deny support to older language standards on compilers that do comply with them? No doubt it should benefit from post C++11 features, notably variadic templates, but I don't see why it shouldn't emulate variadics on C++98/03 setups, just like it already does today. Please note the difference between old deffective implementations from valid implementations of older standards.
My proposal is a response to suggestions that we might address the mpl maintenance problem by eliminating support for older compilers and standards. In my opinion, the suggestion has merit in that writing mpl using C++11 features would result in something much easier to maintain and understand. Of course this would not be compatible with C++03 compilers. The only way to have it both ways is to leave the current MPL as it is and add a separately maintained "MPL Lite" or "MPL.core" or whatever which would be C++11+ only. For those who are concerned about the maintainability issue with the current MPL - and actually would be interested in doing something about it - I believe that this would be a good way forward. Of course the original MPL would be around as long as anyone needs it. This is my attempt to suggest something which pleases everyone. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Friday 06 March 2015 10:13:01 Robert Ramey wrote:
My proposal is a response to suggestions that we might address the mpl maintenance problem by eliminating support for older compilers and standards. In my opinion, the suggestion has merit in that writing mpl using C++11 features would result in something much easier to maintain and understand. Of course this would not be compatible with C++03 compilers.
The only way to have it both ways is to leave the current MPL as it is and add a separately maintained "MPL Lite" or "MPL.core" or whatever which would be C++11+ only. For those who are concerned about the maintainability issue with the current MPL - and actually would be interested in doing something about it - I believe that this would be a good way forward.
I think the main question is if that's actually needed. The current MPL works on all compilers, old and new ones. There are little to no maintenance requests. And for new features we have several new candidate libraries, which conveniently drop C++03 already. So dropping C++03 in MPL seems like losing the key advantage (which is compatibility).
2015-03-06 15:13 GMT-03:00, Robert Ramey <ramey@rrsd.com>:
My proposal is a response to suggestions that we might address the mpl maintenance problem by eliminating support for older compilers and standards. In my opinion, the suggestion has merit in that writing mpl using C++11 features would result in something much easier to maintain and understand. Of course this would not be compatible with C++03 compilers.
The only way to have it both ways is to leave the current MPL as it is and add a separately maintained "MPL Lite" or "MPL.core" or whatever which would be C++11+ only. For those who are concerned about the maintainability issue with the current MPL - and actually would be interested in doing something about it - I believe that this would be a good way forward.
Of course the original MPL would be around as long as anyone needs it.
This is my attempt to suggest something which pleases everyone.
No doubt support to defective compilers essentially renders MPL unmaintainable. The only thing of which I'm not so convinced yet, is the notion that keeping compatibility with C++98/03 would be that harmful to maintainability. I still believe it could be managed and, to me, that would be the perfect balance between compatibility and maintainability, hopefully attracting maintainers to MPL(2) once again. 2015-03-06 15:30 GMT-03:00, Andrey Semashev <andrey.semashev@gmail.com>:
I think the main question is if that's actually needed. The current MPL works on all compilers, old and new ones. There are little to no maintenance requests.
Users are still interested in maintaining MPL, as one may see by the handful of bug reports issued in the past 5+ years, the problem has just been finding someone to tackle them. I'm afraid many other bugs might not have been reported for the simple fact users might feel they won't be addressed, just like previous ones haven't still after so many years. As an example, just recently I decided to try addressing some of these bugs and indeed got some feedback from a few maintainers, but I'm still to find someone feeling confident enough with her/his knowledge of MPL to review my pull requests. I find it of grave concern to have such a core library left unmaintained, so, yes, I think it is needed. -- *Bruno C. O. Dutra*
----- Original Message -----
From: "Bruno Dutra" <brunocodutra@gmail.com>
2015-03-06 15:13 GMT-03:00, Robert Ramey <ramey@rrsd.com>:
My proposal is a response to suggestions that we might address the mpl maintenance problem by eliminating support for older compilers and standards. In my opinion, the suggestion has merit in that writing mpl using C++11 features would result in something much easier to maintain and understand. Of course this would not be compatible with C++03 compilers.
The only way to have it both ways is to leave the current MPL as it is and add a separately maintained "MPL Lite" or "MPL.core" or whatever which would be C++11+ only. For those who are concerned about the maintainability issue with the current MPL - and actually would be interested in doing something about it - I believe that this would be a good way forward.
Of course the original MPL would be around as long as anyone needs it.
This is my attempt to suggest something which pleases everyone.
No doubt support to defective compilers essentially renders MPL unmaintainable. The only thing of which I'm not so convinced yet, is the notion that keeping compatibility with C++98/03 would be that harmful to maintainability. I still believe it could be managed and, to me, that would be the perfect balance between compatibility and maintainability, hopefully attracting maintainers to MPL(2) once again.
2c: I would be against another metaprogramming library _unless_ it was based on thoroughly modern C++. It is long past time for Boost to start pushing compilers again at a fundamental compiler implementation level. Regards, Paul Mensonides
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of pmenso57@comcast.net Sent: 07 March 2015 00:30 To: boost@lists.boost.org Subject: Re: [boost] [MPL lite or MPL 2] A modest proposal
----- Original Message -----
From: "Bruno Dutra" <brunocodutra@gmail.com>
2015-03-06 15:13 GMT-03:00, Robert Ramey <ramey@rrsd.com>:
My proposal is a response to suggestions that we might address the mpl maintenance problem by eliminating support for older compilers and standards. In my opinion, the suggestion has merit in that writing mpl using C++11 features would result in something much easier to maintain and understand. Of course this would not be compatible with C++03 compilers.
2c: I would be against another metaprogramming library _unless_ it was based on thoroughly modern C++. It is long past time for Boost to start pushing compilers again at a fundamental compiler implementation level.
+1 Leaving MPL_1 behind means it should aim for Tip-Of-Tree compiler versions so see how much benefit can be gleaned from using C++17ish syntax. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
participants (8)
-
Andrey Semashev -
Bruno Dutra -
Eric Niebler -
Louis Dionne -
Paul A. Bristow -
pmenso57＠comcast.net -
Robert Ramey -
Steven Watanabe