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

19 May 2014

      On Mon, May 19, 2014 at 1:59 PM, Louis Dionne  wrote:
...
Joel de Guzman  writes:
...
On 5/19/14, 9:11 PM, Zach Laine wrote:
...
[...]
That being said, it doesn't look like Louis is committed to one
...
...
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
approach or
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::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 respectively.

Lee

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

Lee Clagett