Re: [boost] [hana] Review

Subject: Re: [boost] [hana] Review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-24 12:39:24

John Bytheway <jbytheway+boost <at> gmail.com> writes:

>
> [...]
> - What is your evaluation of the library's:
>   * Design
>
> The design seems reasonable, and I like the adherence to mathematical
> concepts.  The most difficult thing is getting the names right, and I
> know there's been plenty of debate on that.  The name that most concerns
> me is Range, given that that term is already commonly used in Boost as a
> concept with a completely different meaning (in the Boost.Range sense).

Interval might be reasonable too?

>   * Implementation
>
> Did not look.
>
>   * Documentation
>
> Mostly very good, but of course there is always room for improvement.
> One particular thing I wanted to raise here is that I struggled to find
> enough information about Hana-convertibility (i.e. using the 'to'
> function).  For example, I wondered if I could create a Tuple from a
> Range, and it seems I can.  Then I wondered whether I could create a
> std::Array from a homogeneous Tuple, but it seems I cannot.

A Tuple is a Sequence, and a Sequence can be created from any Foldable. Since
a Range is Foldable, it works. However, a std::array is _not_ a Sequence.

> How should I know these things?

The Foldable -> Sequence conversion is documented in the reference of
Foldable, here: http://ldionne.com/hana/structboost_1_1hana_1_1Foldable.html
However, I agree that it could/should appear closer to the description of the
`to` function. One problem is that a lot of types provide the `to` function,
but I can't really describe all of them in the reference for `to`.

Where should these conversions be documented to make it easier for users to
find them?

> (This latter case of converting to an array is something I feel ought to
> be supported for easing the boundary between runtime and compile-time
> sequences)

std::array is not "general" enough to allow construction from an arbitrary Hana
Sequence. As you point out, it would only work for Sequences containing objects
of a single type. However, this breaks the naturality of the `to` function.
Of course, nothing prevents me from adding a conversion to std::arrays, but
it wouldn't actually fit in Hana's mathematical framework.

I know the above must seem quite fuzzy, so let me try to explain my point by
considering the implementation of a `to<std::array>` conversion:

  namespace boost { namespace hana {
    template <typename S>
    struct to_impl<ext::std::Array, S, when<models<Sequence, S>()>> {
      template <typename Xs>
      static /*constexpr*/ auto apply(Xs&& xs) {
        using T = std::remove_reference_t<decltype(hana::head(xs))>;
        auto len = hana::length(xs);
        return hana::unpack(std::forward<Xs>(xs), [=](auto&& ...x) {
          return std::array<T, len>{{std::forward<decltype(x)>(x)...}};
        });
      }
    };
  }}

See how we make an arbitrary choice to use the type of the first element of the
sequence for `T`? This, and the fact that it will only work when the Sequence
happens to contain elements of a single type, are what breaks naturality.

> [...]
>
> I went looking for some code of mine to try porting to Hana, and got
> sidetracked by one difficulty.  The first project I came across using
> Boost.Fusion was passing a lot of fusion::vectors across function
> interfaces, but the vector types were specific and the functions not
> defined in headers.  Hana's tuple cannot easily be used in this way
> since the type is unspecified.  I don't think this is a problem, because
> (a) that code was just poorly written and ought instead to be using
> adapted structs, which Hana does support, and (b) I can use Hana
> algorithms with Fusion's tuples anyway.

Technically, Hana's tuple has a specified type. That type is `hana::_tuple<...>`.
The name will change to (probably) `hana::tuple<...>`. It is true that most other
data structures have unspecified types, but this is similar to how Fusion's
vectors have numbered forms. I'm curious to know how the original code managed
to pass Fusion vectors across interfaces? Did it make sure to only use the
non-numbered fusion::vector<...> form, or something else?

> - How much effort did you put into your evaluation of the review?
>
> A few hours reading and playing.
>
> Thanks very much to Louis for his effort.  I look forward to being able
> to use Hana in the not-too-distant future, and I'll make GitHub issues
> for any more things I discover in my testing.
>
> John

Thanks a lot for your review, John.

Regards,
Louis