Re: [boost] [GSoC][MPL11] Post C++Now update

Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
From: Joel de Guzman (djowel_at_[hidden])
Date: 2014-05-18 22:09:30

On 5/19/14, 8:47 AM, Hartmut Kaiser wrote:
>
>> On 5/19/14, 4:41 AM, Louis Dionne wrote:
>>> After discussing the issue several times during the week, I (and others)
>>> think it might be possible to merge Fusion and the MPL into a single
>>> library. I am currently trying to write a library that does that. Since
>>> this constitutes a large reorientation, I created a new repository which
>>> is available at [2]. Those with interest should consider subscribing to
>>> the repository to be updated as I make progress.
>>
>> Been there tried that...
>>
>> This has been proposed several times in the past. I reiterate my
>> position: MPL and Fusion are different beasts and it is not good for
>> both to be merged (if it is at all possible). MPL does not have the
>> runtime components that Fusion needs and Fusion has runtime
>> components that MPL *does not* need.
>>
>> Also, because of the runtime aspects of Fusion, the semantics of
>> algorithms do not make sense in MPL. Take the any algo for example:
>>
>>      http://tinyurl.com/mk2whdo
>>
>> Note that odd in that example is a runtime operation. How do you
>> unite that? It works only with fusion sequences (with values)
>> and not with MPL sequences (with types). In MPL, that would be a
>> type-only predicate.
>>
>> If you add values to MPL, it would be 1) unnecessarily more complex
>> than it needs to be and 2) the feature set would be comprised of very
>> ugly mongrels.
>
> FWIW, I 100% agree with Joel. Having MPL and Fusion separate is definitely
> the way to go. Fusion is named the way it is for a reason! If you wanted to
> combine MPL and Fusion you would have to combine it with the STL by simple
> extension as well.
>
> Moreover, Christopher Schmidt finished a full C++11 rewrite of Fusion during
> GSoC 2009. It might be a good idea to go back and look what he came up with.

The C++11 port is probably not good enough in a C++14 world and now
that we know a lot more how to use C++14 properly. Also, my biggest gripe
about that port was that it required one big gulp. I insist on incremental
updates instead of one big switch. One final point is that the current
fusion lib is in active development and incrementally adds more C++11/14
code. I'd welcome co-maintainer(s) to do more work on modernization.
Send me an email if interested.

That said, I'd also welcome a totally modern C++14 Fusion version, without
any C++03-isms and taking advantage of all the cool features of C++14,
without any backward compatibility requirements. I'm willing to mentor
and direct such an effort. Let's call it Fusion14. I welcome proposals
and POCs.

(BTW, MPL11 should be MPL14 instead, using all the features of C++14)

Regards,
-- 
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/