Re: [boost] [hana] Review

Subject: Re: [boost] [hana] Review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-27 10:25:57

> On 2015-06-24 12:39, Louis Dionne wrote:
>
> > [...]
> > 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?
>
> Well, if they are documented in the source concept and the documentation
> for 'to' states that that is where such conversions are documented, then
> I think that's fine.

Good idea. I added this to the documentation of `to`.

> [...]
>
> I understand the concern.
>
> FWIW, the specific use case I was thinking of was being able to do
> something like this for an arbitrary tuple t:
>
> boost::algorithm::join(hana::to<Array>(hana::transform(t, to_string)), "
> ")
>
> because boost::algorithm::join is expecting a runtime Range rather than
> a compile-time one.  Array seemed like the most likely candidate for
> glueing these together.  Do you have any alternative suggestions for
> such situations?

I don't know how generally this applies, but I would suggest the following
for your precise use case:

    boost::algorithm::join(hana::unpack(t, [](auto&& ...x) {
        return std::array<std::string, sizeof...(x)>{{
            to_string(std::forward<decltype(x)>(x))...
        }};
    }), " ");

In addition, this will be lightning fast because unpacking a tuple is very
cheap and you do not require any layer between your call to to_string and
the creation of your array, so you minimize the number of functions that are
instantiated.

> >> [...]
> >>
> >> 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<...>`.
>
> I thought that tuple_t<...> might produce a different type of Tuple?

That is correct, and my comment was unclear. `make_tuple(...)` has a
specified
type, but `tuple_t<...>` does not.

> > 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?
>
> Indeed, it only used the non-numbered versions.  There was one part of
> the code implementing some generic optimization which returned a
> fusion::vector of parameter choices, and then elsewhere this was being
> used in a specific case where the number and type of parameters was
> known, and the resulting parameter vector was just passed around as-is
> rather than converting it to a more meaningful type.

Ok. Might this qualify as a borderline usage of Fusion's implementation
details?

Regards,
Louis

--
View this message in context: http://boost.2283326.n4.nabble.com/hana-Review-tp4677475p4677597.html
Sent from the Boost - Dev mailing list archive at Nabble.com.