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

16 Feb 2018

      AMDG

On 02/16/2018 06:41 AM, Peter Dimov via Boost wrote:
...
...
Steven Watanabe wrote:
...
On 02/15/2018 05:55 PM, Peter Dimov via Boost wrote:
...
<snip>
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.
   What's the point of making libraries if you refuse to use them?
Who is "you" in this sentence?
This wasn't a rhetorical question.
There are three levels at which Hana can be used:
1. hana::tuple in the interface of Yap, resp. in the specification and
tests
2. In the implementation of Yap
3. In user code based on Yap (f.ex. implementing transforms)
For which level do you object to a supposed refusal to use Hana?
I'm going to split (1):
1a. Users passing tuples to Yap should not be restricted
    to hana::tuple.
1b. On the other hand, it's completely reasonable for
    Yap to give hana::tuple to users.  (Yap has to choose
    something, after all)

I think that Yap is closer to 1b than 1a.

(I definitely object to (2) and as for (3), well, if
users don't want to use hana, it's their loss.)
...
Because I was talking about #1.
The thing is, in most cases, the tuple type
is chosen by Yap, not by the user.  Most of the
time, users don't actually need to care what
the tuple type is, either.

template
struct my_expr {
  static const expr_kind kind = K;
  Tuple elements;
};

struct a_transform {
  template<class T>
  auto operator()(terminal_tag, T&&t);
  // ...
};

  Consequently, I think it's fine for Yap to use
whatever is most convenient.  For the record, if
Zach wants to use std::tuple everywhere instead,
I think that's also fine.

In Christ,
Steven Watanabe