$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [hana] Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-24 13:22:55
Le 24/06/15 18:39, Louis Dionne a écrit :
> 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.
Couldn't std::array<T,0> be considered the empty Array and so Array
could be considered a homogeneous 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?
I would put the To function on the Source class it it s a concrete type.
Otherwise on the Target class.
It could be added on a see also section for the other class or concept.
>> (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.
Why not request that the sequence is homogeneous?
Vicente