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

Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-05-18 20:47:47

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

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu