Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Manu Sánchez (manu343726_at_[hidden])
Date: 2015-03-07 11:22:57

Hello guys. I have been reading the whole discussion for a while, and I
think I should put my little humble opinion here.

I have been working on my own C++11 metaprogramming library for two years,
it's called Turbo (https://github.com/Manu343726/Turbo). I know Eric is
aware of my work, due to some spamming on twitter :)

Similar to Meta, all the Turbo machinery is based on tml::eval, a template
alias encapsulating an expression evaluator. The point of eval is not to do
typename::type only, but to evaluate an expression and its arguments first
(recursively). This week I have been working on adding metafunction classes
support to Turbo, that is, now tml::eval is able to evaluate expressions
like std::remove_cv<std::remove_pointer<const int*>> in an eager way like
Meta, and at the same time metafunction classes like the lift example you
provided above:

using Int = tml::eval<std::remove_cv<std::remove_pointer<const int*>>>;

using Tuple = tml::eval<lift<std::tuple>, int, char, bool, double>;

I understand the eager Meta approach, that's what I picked at the beginning
of Turbo, but metafunction classes make customization and composition far
easier in some scenarios. I think the right thing is to take the best of
two worlds, as Turbo currently does.
As an example, the main.cpp file contains several examples of what I'm
currently working on and the power of the eager + metafunction classes way:
There are foldable typelists, mappable typelists, a functor to translate
between typelist categories, a shorthand for haskell-like do notation etc:
https://github.com/Manu343726/Turbo/blob/master/blocks/manu343726/turbo_main/main.cpp

Eager approach by default makes evaluation of simple expressions easier,
but I'm agree with Louis, it's a pain when dealing with lazy and/or
conditional expressions. Try to support both approaches, take the best tool
for each scenario.

PD: The main issue with my tml::eval approach is the complexity of its
implementation. But I'm sure the concept holds, and should be a way to
write this thing simpler from scratch. The current eval.hpp file is the
result of two years of meta-nightmares, workarounds to GCC bugs, etc.

Please let me know if there's any issue with format, correctness, rules,
etc on this message. It's my first time on the mailing list.

Manu Sánchez manu343726.github.io