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
[...]
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.