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

Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
From: Lee Clagett (forum_at_[hidden])
Date: 2014-05-19 14:17:58

On Mon, May 19, 2014 at 1:59 PM, Louis Dionne <ldionne.2_at_[hidden]> wrote:

> Joel de Guzman <djowel <at> gmail.com> writes:
>
> >
> > On 5/19/14, 9:11 PM, Zach Laine wrote:
> > > [...]
> > >
> > > That being said, it doesn't look like Louis is committed to one
> approach or
> > > another yet; he is still investigating.  Also, he is not committed to
> > > making a drop-in Fusion replacement, just an updated MPL for C++11/14.
>  He
> > > is simply trying to incorporate Fusion-like elements in that where
> they are
> > > appropriate.  Louis, please correct me if I'm mistaken.
>
> That's correct. I'm just trying to figure whether it is possible/desirable
> to have a universal metaprogramming library for C++.
>
> Also, there are no plans to build a drop-in replacement for Fusion.
> Whatever
> I come up with won't be backward compatible with Fusion because it won't
> use
> iterators, which I consider as a design flaw. It won't be backward
> compatible
> with the MPL for the same reason.
>
> > Sounds very cool. I'd love to see a proof of concept toy example. Anyone?
> > My concern here is that constexpr has severe limitations. I wonder
> > how useful a fusion library based on constexpr will be.
>
> http://github.com/ldionne/hana
>
>
> Regards,
> Louis Dionne
>

Is the issue the name, MPL11? These proposals seem to be more Fusion11. The
current MPL has type-computation and compile-time value computation. It
supports sequences of types and sequences of homogeneous values. It seems
that people want the compile-time value computation written in the runtime
language, as opposed to the compile time language. I like this idea too.
But I'm not seeing a reason to do type-computation in the runtime-language.
For example, take this in the current current MPL:

template<bool IsOrdered>
struct Values
{
boost::mpl::if_c<IsOrdered, std::set<int>, std::unordered_set<int>>::type
values;
};

And then in the runtime MPL that Louis posted earlier:

template<bool IsOrdered>
struct Values
{
decltype(boost::mpl::if_c(declval(mpl::bool_<IsOrdered>),
declval(std::set<int>), declval(std::unordered_set<int>))) values;
};

That seems like a step backward to me. It is possible to "stitch" together
the runtime and compile languages with the expanded "using" keyword, but is
that the right approach? What would be the benefit of the current MPL for
these sorts of type computations? Maybe the goal is to have the
compile-time value computation merged into a new iteration of a fusion-like
library. All of the Fusion functions could work with std::tuple or
std::integer_sequence, which is equivalent to fusion::vector and
mpl::vector_c<int, ...> respectively.

Lee