Re: [boost] MPL and MPL core

Subject: Re: [boost] MPL and MPL core
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-04-01 09:13:15

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