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