Re: [boost] Yap's formal review is starting now!

Subject: Re: [boost] Yap's formal review is starting now!
From: P F (pfultz2_at_[hidden])
Date: 2018-02-16 05:19:32

> On Feb 15, 2018, at 6:55 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> Zach Laine wrote:
>> > The interface is not more complicated at all. The user just puts an > std::tuple where he'd have put the hana::tuple. The implementation is > more complicated. :-)
>> 
>> Well, mostly, but it's still user-visible.  A transform might pattern match against expressions like this:
>> 
>> struct my_xform {
>> 
>>    template<typename TerminalValue1, typename TerminalValue2>
>>    auto operator()(
>>        plus_tag,
>>        my_expr<expr_kind::terminal, TUPLE<TerminalValue1>> const & lhs,
>>        my_expr<expr_kind::terminal, TUPLE<TerminalValue2>> const & rhs)
>>    { return /*...*/; }
>> 
>> };
>> 
>> If TUPLE can be only std::tuple or hana::tuple, that's a lot easier to write than if it can be any TupleLike.
> 
> That's true in the case where the authors of `my_xform` and `my_expr` are different. If the same person has written both, he would know what tuple to use.
> 
> But yes.
> 
> It's also true that for any nontrivial manipulation you'd need tuple algorithms, which std::tuple doesn't have, as your get_arity example demonstrates. And yet, tying to Hana doesn't feel right.
> 
> I'm thinking about properly completing the "tuple" part of mp11 with all the algorithms that make sense, starting with `transform`, but I doubt I'll have time for that in any near future. 

You can use Boost.HOF(aka Fit) for that. It should be fine for small tuple sizes:

for_each(tup, f)   => unpack(proj(f))(tup)
transform(tup, f)  => unpack(proj(f, construct<std::tuple>()))(tup)
fold(tup, f)       => unpack(fold(f))(tup)
concat(tup1, tup2) => unpack(construct<std::tuple>())(tup1, tup2)

It is a little more to write, but it is fairly trivial vs implementing it yourself.