[mpl] multiset

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[mpl] multiset

Bruno Dutra
Hi Folks,

Anyone knows what's up with this so called "multiset" I just found fiddling
with the source code? The poor thing seems to have been left unfinished :(
Any reasons anyone would not just go ahead and try bringing it to life?

I would definitely be up to take the first step, I just don't know whether
not I should carry on with it, I mean, isn't the whole purpose of all this
is encouraging people like myself to take the step ahead and just do it?

Anyways, MPL seems to have seen better days of activity back in the day,
there's lots of opportunities for improvement still and I for one would be
glad to help developing some fancier features.

I'd be glad to hear what you guys have to say.

Best regards,
*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] multiset

Mathias Gaunard-2
On 11/02/2015 01:25, Bruno Dutra wrote:

> Anyways, MPL seems to have seen better days of activity back in the day,
> there's lots of opportunities for improvement still and I for one would be
> glad to help developing some fancier features.

MPL is not undergoing active development anymore and is just being
maintained.

I believe however that some people were interested in doing a new C++11
version of MPL. I think the problem is that every year or so someone
finds a new fancy way to do meta-programming with the latest C++
features, with noble goals of unifying MPL and Fusion, so most of these
rewrites end up as experiments rather than stable libraries.



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

Re: [mpl] multiset

Bruno Dutra
So what you are trying to say is that MPL is frozen for new features, or
just that so far no attempt of improvement has been proven stable enough? I
mean, is there interest on new features, provided of course their merits
are proven, or the community currently understands MPL should not be
changed beyond necessary fixes?

At least a backward compatible port of MPL taking advantage of C++11 syntax
should be fairly easy to achieve, with the benefits of increasing arity
limits up to compiler variadic limits and even overcoming performance
shortcomings for setups which have variadic templates enabled. All of this
with no need of refactoring on the end user side naturally.
On Feb 13, 2015 9:19 AM, "Mathias Gaunard" <[hidden email]>
wrote:

> On 11/02/2015 01:25, Bruno Dutra wrote:
>
>  Anyways, MPL seems to have seen better days of activity back in the day,
>> there's lots of opportunities for improvement still and I for one would be
>> glad to help developing some fancier features.
>>
>
> MPL is not undergoing active development anymore and is just being
> maintained.
>
> I believe however that some people were interested in doing a new C++11
> version of MPL. I think the problem is that every year or so someone finds
> a new fancy way to do meta-programming with the latest C++ features, with
> noble goals of unifying MPL and Fusion, so most of these rewrites end up as
> experiments rather than stable libraries.
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

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

Re: [mpl] multiset

Gordon Woodhull
Please don't top-post on this list.  Rearranging.

On Feb 13, 2015, at 8:51 AM, Bruno Dutra <[hidden email]> wrote:

> On Feb 13, 2015 9:19 AM, "Mathias Gaunard" <[hidden email]>
> wrote:
>
>> On 11/02/2015 01:25, Bruno Dutra wrote:
>>
>> Anyways, MPL seems to have seen better days of activity back in the day,
>>> there's lots of opportunities for improvement still and I for one would be
>>> glad to help developing some fancier features.
>>>
>>
>> MPL is not undergoing active development anymore and is just being
>> maintained.
>>
>> I believe however that some people were interested in doing a new C++11
>> version of MPL. I think the problem is that every year or so someone finds
>> a new fancy way to do meta-programming with the latest C++ features, with
>> noble goals of unifying MPL and Fusion, so most of these rewrites end up as
>> experiments rather than stable libraries.

> So what you are trying to say is that MPL is frozen for new features, or
> just that so far no attempt of improvement has been proven stable enough? I
> mean, is there interest on new features, provided of course their merits
> are proven, or the community currently understands MPL should not be
> changed beyond necessary fixes?
>
> At least a backward compatible port of MPL taking advantage of C++11 syntax
> should be fairly easy to achieve, with the benefits of increasing arity
> limits up to compiler variadic limits and even overcoming performance
> shortcomings for setups which have variadic templates enabled. All of this
> with no need of refactoring on the end user side naturally.

I'm sure many of us would welcome that.  

For comparison, you should take a look at Louis Dionne's MPL11, which did not end up backward-compatible (but is pretty amazing), and Hana, which strays even further (and combines Fusion and MPL).

https://github.com/ldionne/mpl11
https://github.com/ldionne/hana



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

Re: [mpl] multiset

Bruno Dutra
For comparison, you should take a look at Louis Dionne's MPL11, which did
> not end up backward-compatible (but is pretty amazing), and Hana, which
> strays even further (and combines Fusion and MPL).
>
> https://github.com/ldionne/mpl11
> https://github.com/ldionne/hana
>

I knew there had to be someone out there addressing MPL's shortcomings in a
world where C++03 is increasingly deemed old fashioned.
Hana sounds promissing, I'll check it out.

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

Paul Fultz II
In reply to this post by Mathias Gaunard-2

> I believe however that some people were interested in doing a new C++11
> version of MPL. I think the problem is that every year or so someone
> finds a new fancy way to do meta-programming with the latest C++
> features, with noble goals of unifying MPL and Fusion, so most of these
> rewrites end up as experiments rather than stable libraries.

I think Eric Niebler's meta library is good start for a modern MPL library,
and it doesn't try to unify MPL and Fusion.

Paul
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Paul Fultz II
> I think Eric Niebler's meta library is good start for a modern MPL library,
> and it doesn't try to unify MPL and Fusion.

Also, you can find it here:

https://github.com/ericniebler/meta

Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Bruno Dutra
2015-02-13 15:05 GMT-02:00 pfultz2 <[hidden email]>:

> > I think Eric Niebler's meta library is good start for a modern MPL
> library,
> > and it doesn't try to unify MPL and Fusion.
>
> Also, you can find it here:
>
> https://github.com/ericniebler/meta
>

I see that there seems to be a tendency nowadays for metaprogramming
libraries to inhabit that gray zone between compile and runtime
computations, specially since the advent of generalized constexpr
functions. It seems to me though that embracing constexpr functions within
metaprogramming libraries rather cripples a pure metaprogramming breed on
at least two instances:

1 - rather hackish syntax;
2 - intrinsic dependency on bleeding edge compilers and language standards.

Take hana for example. It is an undeniably impressive piece of work for
what's been designed, but that, in fact, is constexpr computations, which
happen to depend on and thus provide type computations mechanisms. Hence it
suffers of the two shortcomings I mentioned.

MPL on the other hand, being a [almost] pure metaprogramming library
manages to avoid these shortcomings. Compatible even to C++98, no wonder so
many other boost libraries depend on it. MPL is however over 10 years of
age and could definitely use some polishing, but I see no reason backwards
compatibility should be dropped, like it has for the three examples you
guys mentioned.

Anyways, I don't have the necessary background to make such assertions, but
I believe MPL still has a lot of room to expand within its niche and it
baffles me that there has long been no group activelly improving it.
Perhaps I'm just too stuborn and should better move on to hana. Well, I'd
definitely appreciate some thoughts.

Kind regards,
*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] multiset

Vicente Botet
In reply to this post by Paul Fultz II
Le 13/02/15 18:03, pfultz2 a écrit :
>> I believe however that some people were interested in doing a new C++11
>> version of MPL. I think the problem is that every year or so someone
>> finds a new fancy way to do meta-programming with the latest C++
>> features, with noble goals of unifying MPL and Fusion, so most of these
>> rewrites end up as experiments rather than stable libraries.
> I think Eric Niebler's meta library is good start for a modern MPL library,
> and it doesn't try to unify MPL and Fusion.
>
+1

While I appreciate the work on Hana, I believe a pure meta-programming
(pure functional) C++11/C++14 library would make things easier.

What about enriching the Eric's library on a GSoC project?

Vicente

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

Re: [mpl] multiset

Niall Douglas
In reply to this post by Bruno Dutra
On 19 Feb 2015 at 11:59, Bruno Dutra wrote:

> Take hana for example. It is an undeniably impressive piece of work for
> what's been designed, but that, in fact, is constexpr computations, which
> happen to depend on and thus provide type computations mechanisms. Hence it
> suffers of the two shortcomings I mentioned.

The list may not be aware that Boost is funding a GSoC extension for
Hana, which is currently about half way through. It is currently
expected that Hana will reapply for an additional GSoC this summer as
well. Quality software takes time. Remember Louis has a full
coursework load.

Regarding compiler compatibility, Hana almost certainly should work
on GCC 5.0 and Louis nearly has it working on GCC 4.9. I'd imagine
the compiler which will take the longest is as usual MSVC, but there
is a reasonable chance that a VS2017 might just provide enough for
Hana, albeit with many workarounds for the lack of two phase lookup.

The "hackish" syntax you mention is partially unavoidable with C++,
and partially because constexpr was very poorly thought through as a
language feature in that it is much too hard to get constexpr to be
exact. This is regrettable, but the ship has sailed now, just as we
currently overload template syntax with functional compile time
programming which is definitely hackish. If we were sensible, we
would deprecate that in favour of something like D's compile time
programming syntax, but progress on introducing D style syntax has
been oddly partial (functions mostly).

Niall

---
Boost C++ Libraries Google Summer of Code 2015 admin
https://svn.boost.org/trac/boost/wiki/SoC2015




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

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Niall Douglas
In reply to this post by Vicente Botet
On 19 Feb 2015 at 15:39, Vicente J. Botet Escriba wrote:

> Le 13/02/15 18:03, pfultz2 a écrit :
> >> I believe however that some people were interested in doing a new C++11
> >> version of MPL. I think the problem is that every year or so someone
> >> finds a new fancy way to do meta-programming with the latest C++
> >> features, with noble goals of unifying MPL and Fusion, so most of these
> >> rewrites end up as experiments rather than stable libraries.
> > I think Eric Niebler's meta library is good start for a modern MPL library,
> > and it doesn't try to unify MPL and Fusion.
> >
> +1
>
> While I appreciate the work on Hana, I believe a pure meta-programming
> (pure functional) C++11/C++14 library would make things easier.
>
> What about enriching the Eric's library on a GSoC project?
Sufficiently able students are extremely tough to find. Also, Eric's
Meta is very new, is C++ 14 only, and I assume would internal
compiler error any MSVC :)

That said if you're willing to mentor such a GSoC Vicente ...

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/




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

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Bruno Dutra
In reply to this post by Niall Douglas
>
> Regarding compiler compatibility, Hana almost certainly should work
> on GCC 5.0 and Louis nearly has it working on GCC 4.9. I'd imagine
> the compiler which will take the longest is as usual MSVC, but there
> is a reasonable chance that a VS2017 might just provide enough for
> Hana, albeit with many workarounds for the lack of two phase lookup.
>

That is what I mean by dependencies on bleeding edge compilers. Sure, soon
enough these currently experimental compiler versions are going to become
mainstream across most  popular setups, but what about legacy applications
or embedded systems for which, as my very limited experience has taught me,
full standard compliant compilers are rarely provided?


> The "hackish" syntax you mention is partially unavoidable with C++,
> and partially because constexpr was very poorly thought through as a
> language feature in that it is much too hard to get constexpr to be
> exact. This is regrettable, but the ship has sailed now, just as we
> currently overload template syntax with functional compile time
> programming which is definitely hackish. If we were sensible, we
> would deprecate that in favour of something like D's compile time
> programming syntax, but progress on introducing D style syntax has
> been oddly partial (functions mostly).
>

By "hackish" I just ment that decltype-ing constexpr functions to perform
type computations feels rather odd. I'm aware this is mostly a matter of
personal taste, but I'm still skeptical that this idiom would allow type
computations as straightforwardly as traditional template overloading does.
As soon as I have time I will try to implement some fancier logic
predicates using Hana, like unification and SLD resolution, and compare the
verbosity with a traditional approach. Hopefuly it proves me wrong.

Please bear in mind however that I don't mean to diminish Hana by any
means, on the contrary, as I said, I'm very much impressed by its elegance
in accomplishing the task for which it was built. I just advocate that it
fills a very different niche than its predecessor MPL, which, in my opinion
should not be left aside, specially considering its ability to be compiled
by virtually any compiler version targeting any architecture of the last
decade.

I'm just wondering whether the lack of development of MPL in the past years
is just incidental, as developers moved on to new frontiers, or if indeed
if reflects a consensus that MPL is obsolete nowadays, which I find hard to
believe.

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

Edward Diener-3
On 2/19/2015 12:34 PM, Bruno Dutra wrote:

>>
>> Regarding compiler compatibility, Hana almost certainly should work
>> on GCC 5.0 and Louis nearly has it working on GCC 4.9. I'd imagine
>> the compiler which will take the longest is as usual MSVC, but there
>> is a reasonable chance that a VS2017 might just provide enough for
>> Hana, albeit with many workarounds for the lack of two phase lookup.
>>
>
> That is what I mean by dependencies on bleeding edge compilers. Sure, soon
> enough these currently experimental compiler versions are going to become
> mainstream across most  popular setups, but what about legacy applications
> or embedded systems for which, as my very limited experience has taught me,
> full standard compliant compilers are rarely provided?
>
>
>> The "hackish" syntax you mention is partially unavoidable with C++,
>> and partially because constexpr was very poorly thought through as a
>> language feature in that it is much too hard to get constexpr to be
>> exact. This is regrettable, but the ship has sailed now, just as we
>> currently overload template syntax with functional compile time
>> programming which is definitely hackish. If we were sensible, we
>> would deprecate that in favour of something like D's compile time
>> programming syntax, but progress on introducing D style syntax has
>> been oddly partial (functions mostly).
>>
>
> By "hackish" I just ment that decltype-ing constexpr functions to perform
> type computations feels rather odd. I'm aware this is mostly a matter of
> personal taste, but I'm still skeptical that this idiom would allow type
> computations as straightforwardly as traditional template overloading does.
> As soon as I have time I will try to implement some fancier logic
> predicates using Hana, like unification and SLD resolution, and compare the
> verbosity with a traditional approach. Hopefuly it proves me wrong.
>
> Please bear in mind however that I don't mean to diminish Hana by any
> means, on the contrary, as I said, I'm very much impressed by its elegance
> in accomplishing the task for which it was built. I just advocate that it
> fills a very different niche than its predecessor MPL, which, in my opinion
> should not be left aside, specially considering its ability to be compiled
> by virtually any compiler version targeting any architecture of the last
> decade.
>
> I'm just wondering whether the lack of development of MPL in the past years
> is just incidental, as developers moved on to new frontiers, or if indeed
> if reflects a consensus that MPL is obsolete nowadays, which I find hard to
> believe.

I believe it reflects the fact that the two developers mostly
responsible for creating MPL are not very active in Boost anymore.

A while back Stephen Kelly specified changes to MPL to get rid of  hacks
for old compilers that nobody should be using anymore, and which would
simplify the MPL code a bit so that new development could more easily be
done with the code. But these changes were never made and the opinion
was voiced that Hana would supercede MPL so why make any changes to MPL
itself. I am with you in believing that until a new  metaprogramming
idiom becomes more popular, such as Hana or maybe Eric's blog
contribution, it is worthwhile looking at possible improvements in MPL
and it is certainly worthwhile fixing any bug reports which may have
been made against MPL.

I can understand the nervousness by which others view any changes to
MPL, since it is so heavily used by other libraries and such a core
library, but I do not understand the point of view that MPL should
remain as frozen as possible so as not to cause problems with other
libraries which use it.


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

Re: [mpl] multiset

Steve M. Robbins-2
On Thu, Feb 19, 2015 at 03:28:54PM -0500, Edward Diener wrote:

> I can understand the nervousness by which others view any changes to MPL,
> since it is so heavily used by other libraries and such a core library, but

That's a good thing: it's a built-in regression test!  :-)

-Steve


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

signature.asc (180 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Robert Ramey
In reply to this post by Edward Diener-3
Edward Diener-3 wrote
> I'm just wondering whether the lack of development of MPL in the past years
> is just incidental, as developers moved on to new frontiers, or if indeed
> if reflects a consensus that MPL is obsolete nowadays, which I find hard to
> believe.

I believe it reflects the fact that the two developers mostly
responsible for creating MPL are not very active in Boost anymore.
The mpl library provides functionality which is no where else available
and which many boost libraries depend on.  

I believe that the fact is that no one is responsible for it anymore.

Just eliminating a few hacks in it is not the same as taking responsibility for it.

A while back Stephen Kelly specified changes to MPL to get rid of  hacks
for old compilers that nobody should be using anymore, and which would
simplify the MPL code a bit so that new development could more easily be
done with the code.

This effort had a couple of issues.  First it changed the scope of mpl from
a library which would support older compilers to one which would limit
support to a more modern subset.  This basically amounts to a change
of interface.  Another problem is that making such changes is much, much
tricker than first meets the eye.  It would be huge effort to do it right.
The right way would be to:

define MPL2 - a C++11+ version of mpl.  Re-implement MPL in terms
of C++11.  This could skip any part of mpl already in the standard.
Presumably it would be a much smaller effort than the original, but it
would still be a very large effort.  Remember that MPL is the result of
efforts of two of the best C++ programmers anywhere.  It would be
hard to meet that standard.  Of course anyone is willing to try, feel free.
But these changes were never made and the opinion
was voiced that Hana would supercede MPL so why make any changes to MPL
itself. I am with you in believing that until a new  metaprogramming
idiom becomes more popular, such as Hana or maybe Eric's blog
contribution.
The jury is still out on these efforts.  My concern about hana is that it
seems to have evolved way beyond what MPL does and so wouldn't
serve as a "drop-in" improvement.  I don't know about Eric's effort
but I believe he's said he can't bring to the level of a boost library
and no one has expressed any interest.
 it is worthwhile looking at possible improvements in MPL
and it is certainly worthwhile fixing any bug reports which may have
been made against MPL.

I can understand the nervousness by which others view any changes to
MPL, since it is so heavily used by other libraries and such a core
library, but I do not understand the point of view that MPL should
remain as frozen as possible so as not to cause problems with other
libraries which use it.
I think the main concern is that someone makes a fix - which fixes
his problem - but then walks away from it. Then something breaks
and the next person does the same thing.  That's not the same as
having a maintainer take responsibility for it.

This is an instance of our larger problem of finding a way to keep
maintainers for libraries.  It's still not even close to being solved.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Edward Diener-3
On 2/19/2015 5:19 PM, Robert Ramey wrote:

> Edward Diener-3 wrote
>>> I'm just wondering whether the lack of development of MPL in the past
>>> years
>>> is just incidental, as developers moved on to new frontiers, or if indeed
>>> if reflects a consensus that MPL is obsolete nowadays, which I find hard
>>> to
>>> believe.
>>
>> I believe it reflects the fact that the two developers mostly
>> responsible for creating MPL are not very active in Boost anymore.
>
> The mpl library provides functionality which is no where else available
> and which many boost libraries depend on.
>
> I believe that the fact is that no one is responsible for it anymore.
>
> Just eliminating a few hacks in it is not the same as taking responsibility
> for it.

You are right about this. But MPL is a large library and it should not
need total comprehension for a Boost developer to make changes to a
small part of that library if the changes made improve MPL in some way.

>
> A while back Stephen Kelly specified changes to MPL to get rid of  hacks
> for old compilers that nobody should be using anymore, and which would
> simplify the MPL code a bit so that new development could more easily be
> done with the code.
>
> This effort had a couple of issues.  First it changed the scope of mpl from
> a library which would support older compilers to one which would limit
> support to a more modern subset.

Is Boost seriously supposed to support largely obsolete compilers into
perpetuity with each new release ? I do not think this is viable in all
cases and cannot see this as a goal of Boost libraries. At some point,
with some new release, I think it is possible to say for a given library
that it does not support a largely obsolete compiler.

>  This basically amounts to a change
> of interface.

In the case of Stephen Kelly's removal of old compiler workarounds it
does not. The interfaces would have remained the same but hacks to
support VC6 and VC7, as well as some other compilers that no one should
seriously be using anymore, would have been eliminated. My own feeling
is that the improvement in making MPL code more understandable would
have easily been worth removing these ancient hacks and the compilers
they supported.

>  Another problem is that making such changes is much, much
> tricker than first meets the eye.  It would be huge effort to do it right.

For the removal of MPL hacks that Stephen Kelly did I believe he got
everything right. But since we never got to try it, even in 'develop',
we will never know.

> The right way would be to:
>
> define MPL2 - a C++11+ version of mpl.  Re-implement MPL in terms
> of C++11.  This could skip any part of mpl already in the standard.
> Presumably it would be a much smaller effort than the original, but it
> would still be a very large effort.  Remember that MPL is the result of
> efforts of two of the best C++ programmers anywhere.  It would be
> hard to meet that standard.  Of course anyone is willing to try, feel free.

That is a much bigger change than what Stephen Kelly had tried to do.
That does not mean I do not think it might be worthwhile if someone
talented enough and with time enough were to do it.

>
>> But these changes were never made and the opinion
>> was voiced that Hana would supercede MPL so why make any changes to MPL
>> itself. I am with you in believing that until a new  metaprogramming
>> idiom becomes more popular, such as Hana or maybe Eric's blog
>> contribution.
>
> The jury is still out on these efforts.  My concern about hana is that it
> seems to have evolved way beyond what MPL does and so wouldn't
> serve as a "drop-in" improvement.  I don't know about Eric's effort
> but I believe he's said he can't bring to the level of a boost library
> and no one has expressed any interest.
>
>>   it is worthwhile looking at possible improvements in MPL
>> and it is certainly worthwhile fixing any bug reports which may have
>> been made against MPL.
>>
>> I can understand the nervousness by which others view any changes to
>> MPL, since it is so heavily used by other libraries and such a core
>> library, but I do not understand the point of view that MPL should
>> remain as frozen as possible so as not to cause problems with other
>> libraries which use it.
>
> I think the main concern is that someone makes a fix - which fixes
> his problem - but then walks away from it. Then something breaks
> and the next person does the same thing.  That's not the same as
> having a maintainer take responsibility for it.

If anyone changes anything in a library which breaks anything else it is
that person's responsibility to fix things. This is true whether it is
MPL or anything else. I agree it would be good to have a maintainer for
MPL but a single person trying to take over from Dave and Alexey would
be a very difficult responsibility. Still I see nothing wrong with
others who have maintainer status with MPL making changes as long as
they take responsibility for what they do and of course realize how
important and central MPL is to so many other Boost libraries so they
must be very careful.

>
> This is an instance of our larger problem of finding a way to keep
> maintainers for libraries.  It's still not even close to being solved.
>
> Robert Ramey



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

Re: [mpl] multiset

Robert Ramey
Edward Diener-3 wrote
If anyone changes anything in a library which breaks anything else it is
that person's responsibility to fix things. This is true whether it is
MPL or anything else.
Agreed.  The problem is that people who just need a small fix sometimes
fail to appreciate the subtle repercussions of that that fix.  They go ahead and
do it and then figure they're done - sometimes without even running the
whole test suite.

I don't have an alternative idea.

One thing that might be useful would be to set an explicit policy like
"MPL is only guaranteed to works with:
MSVC 8.0 and above
GCC ?? and above
etc.

I wouldn't suggest anyone go in an start ripping out support for
all the old stuff.  But if someone is in there in the course of fixing
something else, it would be fine - especially since it can't be tested
anymore anyway.
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] multiset

Bruno Dutra
>>> I'm just wondering whether the lack of development of MPL in the past
>>> years
>>> is just incidental, as developers moved on to new frontiers, or if
>>> indeed
>>> if reflects a consensus that MPL is obsolete nowadays, which I find hard
>>> to
>>> believe.
>>
>> I believe it reflects the fact that the two developers mostly
>> responsible for creating MPL are not very active in Boost anymore.
>
> The mpl library provides functionality which is no where else available
> and which many boost libraries depend on.
>
> I believe that the fact is that no one is responsible for it anymore.
> [...]
> My concern about hana is that it
> seems to have evolved way beyond what MPL does and so wouldn't
> serve as a "drop-in" improvement.  I don't know about Eric's effort
> but I believe he's said he can't bring to the level of a boost library
> and no one has expressed any interest.

That's exactly the point I was trying to make. Hana is awesome, but it
doesn't fit as a replacement for MPL, simply because it was meant for
a different purpose. I see no reason why they shouldn't live side by
side, each filling its specific niche.

> The right way would be to:
> define MPL2 - a C++11+ version of mpl.  Re-implement MPL in terms
> of C++11.  This could skip any part of mpl already in the standard.
> Presumably it would be a much smaller effort than the original, but it
> would still be a very large effort.  Remember that MPL is the result of
> efforts of two of the best C++ programmers anywhere.  It would be
> hard to meet that standard.  Of course anyone is willing to try, feel free.
>[...]
> One thing that might be useful would be to set an explicit policy like
> "MPL is only guaranteed to works with:
> MSVC 8.0 and above
> GCC ?? and above
> etc.

That is certainly an audacious idea, but I don't see a better way of
seriously revamping MPL either. I think that was precisely the
original intention of Louis Dionne's MPL11, which ended up deviating
its course and dropping backward API compatibility. Quoting from MPL11
github page:

"This was initially supposed to be a simple C++11 reimplementation of
the Boost.MPL. However, for reasons documented in the rationales, the
library was redesigned and the name does not fit so well anymore."

Perhaps it would be easier to just start off MPL11 and reintroduce
backward compatibility than to start anew.
I wouldn't go so bold as to assert I'm up to the task, but I take it
as a great opportunity for learning and amusing myself, so I'll look
into it at the slow pace my busy life allows me.

That said, I'm with Edward Diener in believing there's lots of room
for improvement in the library as it is and that one should not be
afraid of pushing it forward bit by bit. I understand the concerns
regarding breaking compatibility for older setups, but aren't there
volunteers who run test suites daily, precisely to assure everything
is working as expected across the various setups? One thing that I
noticed though, is that MPL test suite right now does not cover
anywhere near even the documented API, let alone corner cases which
should definitely be tested (running algorithms on empty sequences
comes to mind). A bugfix on which I'm working right now, for instance,
would have been caught a decade ago, had tests been written to cover
the fact, which is explicitly written in the documentation, that
insert_range should work for "Extensible Associative Sequences". As
soon as I get this bug fixed (which is taking way longer than it
should, I must admit), I'll work on expanding current test cases based
on the documentation and file a pull request for that. I just count on
you boost maintainers to help me out by reviewing and accepting my
pull requests as appropriate :)

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

Louis Dionne
Bruno Dutra <brunocodutra <at> gmail.com> writes:

> > My concern about hana is that it
> > seems to have evolved way beyond what MPL does and so wouldn't
> > serve as a "drop-in" improvement.  I don't know about Eric's effort
> > but I believe he's said he can't bring to the level of a boost library
> > and no one has expressed any interest.
>
> That's exactly the point I was trying to make. Hana is awesome, but it
> doesn't fit as a replacement for MPL, simply because it was meant for
> a different purpose. I see no reason why they shouldn't live side by
> side, each filling its specific niche.

I'm a bit late in the game because this thread has gone under my radar;
please excuse that, I was busy working on Hana :-).

Hana was designed as a replacement for both the MPL and Fusion. Technically,
everything you can express with the MPL can be expressed with Hana; I'm
working on a mathematical proof for it. The question really is whether it is
_convenient_ to do so, and my current opinion is yes. However, metaprogramming
with Hana requires you to stop thinking in a MPL way, i.e. with traditional
metafunctions. If you keep your old MPL habits, you will end up having to
decltype function call expressions all the time, which I agree is cumbersome.
If you embrace this new way of metaprogramming, you will only have to use
decltype at some precise boundaries; when you actually _need_ a type at the
end of the whole computation. My assumption in designing Hana was that while
all of our current type-level computations are implemented at the type-level,
this is just a side effect of using the MPL and we actually need the types
only at some thin boundaries.

I suspect
(1) the lack of guidelines for doing type-level metaprogramming in Hana
(2) the lack of a serious case study (e.g. implementing Phoenix with Hana)
could be why people don't see Hana as being fit for a MPL replacement; they
don't see how we can achieve type-level metaprogramming easily, which is
legitimate given (1) and (2).

I clarified the tutorial[1] to improve the situation of (1), but there is
still room for improvement. As for (2), I guess I am the one who should take
the lead; if someone has a suggestion for a good guinea pig, please let me
know. Otherwise, I started implementing the core of Accumulators with Hana;
we'll see how that goes.

FWIW, I am personally not in favor of having two metaprogramming libraries
living side by side. This causes code duplication and interoperation issues,
and it also increases the learning curve. Also, you won't be able to backport
MPL11 to MPL because I diverged from the MPL in a rather major way by using
lazy metafunctions in MPL11. They are more composable and you also don't have
to write "typename" everywhere, but it breaks backward compatibility pretty
severely.

As a final note: if you have comments, doubts or other thoughts about Hana,
please express them by either posting on this list or (even better) opening
a GitHub[2] issue. If I know what people need, I can make sure that Hana
satisfies them properly.

I will be asking for an informal review shortly, so stay tuned.

Regards,
Louis

[1]: http://ldionne.github.io/hana
[2]: https://github.com/ldionne/hana



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

Re: [mpl] multiset

Edward Diener-3
On 2/22/2015 5:36 PM, Louis Dionne wrote:

> Bruno Dutra <brunocodutra <at> gmail.com> writes:
>
>>> My concern about hana is that it
>>> seems to have evolved way beyond what MPL does and so wouldn't
>>> serve as a "drop-in" improvement.  I don't know about Eric's effort
>>> but I believe he's said he can't bring to the level of a boost library
>>> and no one has expressed any interest.
>>
>> That's exactly the point I was trying to make. Hana is awesome, but it
>> doesn't fit as a replacement for MPL, simply because it was meant for
>> a different purpose. I see no reason why they shouldn't live side by
>> side, each filling its specific niche.
>
> I'm a bit late in the game because this thread has gone under my radar;
> please excuse that, I was busy working on Hana :-).
>
> Hana was designed as a replacement for both the MPL and Fusion. Technically,
> everything you can express with the MPL can be expressed with Hana; I'm
> working on a mathematical proof for it. The question really is whether it is
> _convenient_ to do so, and my current opinion is yes. However, metaprogramming
> with Hana requires you to stop thinking in a MPL way, i.e. with traditional
> metafunctions. If you keep your old MPL habits, you will end up having to
> decltype function call expressions all the time, which I agree is cumbersome.
> If you embrace this new way of metaprogramming, you will only have to use
> decltype at some precise boundaries; when you actually _need_ a type at the
> end of the whole computation. My assumption in designing Hana was that while
> all of our current type-level computations are implemented at the type-level,
> this is just a side effect of using the MPL and we actually need the types
> only at some thin boundaries.
>
> I suspect
> (1) the lack of guidelines for doing type-level metaprogramming in Hana
> (2) the lack of a serious case study (e.g. implementing Phoenix with Hana)
> could be why people don't see Hana as being fit for a MPL replacement; they
> don't see how we can achieve type-level metaprogramming easily, which is
> legitimate given (1) and (2).
>
> I clarified the tutorial[1] to improve the situation of (1), but there is
> still room for improvement. As for (2), I guess I am the one who should take
> the lead; if someone has a suggestion for a good guinea pig, please let me
> know. Otherwise, I started implementing the core of Accumulators with Hana;
> we'll see how that goes.

Hana can be a completely differently designed library from MPL, as you
have expressed it, without negating its value in any way.

>
> FWIW, I am personally not in favor of having two metaprogramming libraries
> living side by side. This causes code duplication and interoperation issues,
> and it also increases the learning curve. Also, you won't be able to backport
> MPL11 to MPL because I diverged from the MPL in a rather major way by using
> lazy metafunctions in MPL11. They are more composable and you also don't have
> to write "typename" everywhere, but it breaks backward compatibility pretty
> severely.

Numerous Boost libraries currently use MPL. If you want to have Hana as
a Boost library, if it is accepted after review, I think you will have
to get used to the idea that Boost will have more than one
metaprogramming library. If Hana proves popular enough with
metaprogrammers they will switch away from MPL to Hana.

I do not know what you mean by "two metaprogramming libraries
living side by side" but I believe that two libraries whose purposes are
similar but whose programming interfaces are different is never a
detriment to Boost as long as both are quality libraries which other
programmers find useful.

>
> As a final note: if you have comments, doubts or other thoughts about Hana,
> please express them by either posting on this list or (even better) opening
> a GitHub[2] issue. If I know what people need, I can make sure that Hana
> satisfies them properly.
>
> I will be asking for an informal review shortly, so stay tuned.
>
> Regards,
> Louis
>
> [1]: http://ldionne.github.io/hana
> [2]: https://github.com/ldionne/hana



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