$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