[MPL lite or MPL 2] A modest proposal

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[MPL lite or MPL 2] A modest proposal

Robert Ramey
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
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

Steven Watanabe-4
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


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

Re: [MPL lite or MPL 2] A modest proposal

Eric Niebler-4
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

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

Re: [MPL lite or MPL 2] A modest proposal

Bruno Dutra
2015-03-04 19:17 GMT-03:00 Robert Ramey <[hidden email]>:

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

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

Re: [MPL lite or MPL 2] A modest proposal

Robert Ramey
In reply to this post by Eric Niebler-4
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.
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

Robert Ramey
In reply to this post by Steven Watanabe-4
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.
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

Robert Ramey
In reply to this post by Bruno 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.
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

pabristow
In reply to this post by Robert Ramey
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Robert Ramey
> Sent: 04 March 2015 22:18
> To: [hidden email]
> 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






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

Re: [MPL lite or MPL 2] A modest proposal

Andrey Semashev-2
In reply to this post by Robert Ramey
On Thu, Mar 5, 2015 at 1:17 AM, Robert Ramey <[hidden email]> 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

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

Re: [MPL lite or MPL 2] A modest proposal

Robert Ramey
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.
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

Bruno Dutra
2015-03-05 12:04 GMT-03:00, Robert Ramey <[hidden email]>:
> 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*

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

Re: [MPL lite or MPL 2] A modest proposal

Steven Watanabe-4
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


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

Re: [MPL lite or MPL 2] A modest proposal

Louis Dionne
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



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

Re: [MPL lite or MPL 2] A modest proposal

Bruno Dutra
In reply to this post by Steven Watanabe-4
2015-03-05 15:57 GMT-03:00, Steven Watanabe <[hidden email]>:
> 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*

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

Re: [MPL lite or MPL 2] A modest proposal

Robert Ramey
In reply to this post by Bruno Dutra
Bruno Dutra wrote
2015-03-05 12:04 GMT-03:00, Robert Ramey <[hidden email]>:
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [MPL lite or MPL 2] A modest proposal

Andrey Semashev-2
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).


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

Re: [MPL lite or MPL 2] A modest proposal

Bruno Dutra
In reply to this post by Robert Ramey
2015-03-06 15:13 GMT-03:00, Robert Ramey <[hidden email]>:

> 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 <[hidden email]>:
> 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*

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

Re: [MPL lite or MPL 2] A modest proposal

Paul Mensonides
----- Original Message -----
> From: "Bruno Dutra" <[hidden email]>

> 2015-03-06 15:13 GMT-03:00, Robert Ramey <[hidden email]>:
> > 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

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

Re: [MPL lite or MPL 2] A modest proposal

pabristow
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: 07 March 2015 00:30
> To: [hidden email]
> Subject: Re: [boost] [MPL lite or MPL 2] A modest proposal
>
> ----- Original Message -----
> > From: "Bruno Dutra" <[hidden email]>
>
> > 2015-03-06 15:13 GMT-03:00, Robert Ramey <[hidden email]>:
> > > 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





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