MPL and MPL core

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

MPL and MPL core

Edward Diener-3
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.


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

Re: MPL and MPL core

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


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

Re: MPL and MPL core

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

Re: MPL and MPL core

Bruno Dutra
On Mar 29, 2015 2:40 PM, "Robert Ramey" <[hidden email]> 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/compat

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

Re: MPL and MPL core

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

Re: MPL and MPL core

Bruno Dutra
2015-03-30 21:25 GMT-03:00 Robert Ramey <[hidden email]>:

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

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

Re: MPL and MPL core

Peter Dimov-2
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.


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

Re: MPL and MPL core

Fletcher, John P

________________________________________
From: Boost [[hidden email]] on behalf of Peter Dimov [[hidden email]]
Sent: 31 March 2015 22:42
To: [hidden email]
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



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

Re: MPL and MPL core

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

Re: MPL and MPL core

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

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

Re: MPL and MPL core

Peter Dimov-2
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.


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

Re: MPL and MPL core

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

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

Re: MPL and MPL core

Peter Dimov-2
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.


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

Re: MPL and MPL core

Bruno Dutra
In reply to this post by Eric Niebler-4
2015-04-01 0:00 GMT-03:00 Eric Niebler <[hidden email]>:

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

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

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

Re: MPL and MPL core

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

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

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

Re: MPL and MPL core

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

Re: MPL and MPL core

pabristow
In reply to this post by Paul Mensonides


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: 01 April 2015 05:02
> To: [hidden email]
> Subject: Re: [boost] MPL and MPL core
>
> ----- Original Message -----
> > From: "Bruno Dutra" <[hidden email]>
>
> > > 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






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

Re: MPL and MPL core

Bruno Dutra
In reply to this post by Robert Ramey
On Apr 1, 2015 1:16 AM, "Robert Ramey" <[hidden email]> 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" <[hidden email]> wrote:
>
> > -----Original Message-----
> > From: Boost [mailto:[hidden email]] On Behalf Of
[hidden email]

> > Sent: 01 April 2015 05:02
> > To: [hidden email]
> > Subject: Re: [boost] MPL and MPL core
> >
> > ----- Original Message -----
> > > From: "Bruno Dutra" <[hidden email]>
> >
> > > > 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

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

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

Re: MPL and MPL core

Louis Dionne
In reply to this post by Eric Niebler-4
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



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

Re: MPL and MPL core

Bruno Dutra
2015-04-01 10:13 GMT-03:00, Louis Dionne <[hidden email]>:
[...]
>     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*

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