Re: [boost] Boost Hana comments

Subject: Re: [boost] Boost Hana comments
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-08-21 09:36:55

Jeremy Maitin-Shepard <jeremy <at> jeremyms.com> writes:

> 
> [...]
> > 
> > This is part of the rationale. There's also the fact that integral_constant 
> > requires including <type_traits>, which is about the size of the whole
> > library; I find this annoying. I'll document that.
> 
> I didn't think about that.  It seems to me though that most headers that do
> metaprogramming will also require type_traits anyway.  Still, it is great to
> minimize dependencies when possible.

It might be true on the user side, but it isn't on the library's. Very few 
Hana headers need type traits to function, and when they do they usually need
only one or two type traits, not the whole package -- hence the small 
<type_traits> emulation in hana/detail/. Since I don't want to assume that my 
users are including <type_traits>, I prefer staying minimal. That being said, 
if I end up rewriting too many type traits then I'll definitely use the header
provided by the standard.

> > > Logical type class:
> > > -------------------
> > > 
> > > What is really gained by making this a type class at all?
> > 
> > Yes; how would you branch at compile-time otherwise? The if_ method for e.g. 
> > Integrals is not equivalent to a normal C++ if-statement; it allows both 
> > branches to have different and incompatible types. Also, since we want to
> > be able to branch on `integral`s but also on `mpl::integral_c`s, we need a 
> > type class. 
> 
> As I see it, there are two types of Logical: compile-time and run-time. 
> Both cases have to be handled separately, and there needs to be a way to
> figure out which type of logical a given argument is, but that is it.  The
> implementation of eval_if will be the same, modulo some change of names, for
> hana integral, mpl::integral_c, and std::integral_constant.

I think I'm not getting your point. What you say is true, but it seems to me
that this is a good use case for type classes -- many types sharing the same
interface with (even only slightly) different implementations.

That being said, I've experimented locally with implementing laziness and
branching -- which are awfully related -- through comonads. Basically, I think
comonads might provide an abstract way of representing what is a "branch" in
a usual strict programming language. I'm not giving more details because I 
haven't figured it out completely yet, but if that works out then the Logical
type class would probably change quite a bit. In other words; I think we need
a type class to represent conditional branching, but I am unsatisfied too with
the current solution.

> [...]
>
> Maybe and_ and or_ could just be optimized for hana integral_c.  Since the
> goal is efficiency it seems it may be hard to have it more generic.

I don't see an easy way of optimizing and_ and or_ for hana::integral, since 
they take variadic arguments. We would need to know that all the arguments are 
hana::integrals, which is a bit costly to determine. Furthermore, the logical 
operations I presented at C++Now were not short-circuitting, and we need and_ 
and or_ to short-circuit.

That being said, if you want an efficient non short-circuitting logical and_,
instead of

    // MPL11 (roughly as shown at C++Now)
    template <typename ...T>
    using some_condition = and_<Predicate<T>::value...>;

you could write

    // Hana
    template <typename ...T>
    auto some_condition = all_of(integer_list<bool, Predicate<T>::value>);

Writing this, you are explicitly stating all the prior knowledge needed to
perform optimizations, i.e.

1. "I don't care about short-circuitting", since you evaluate the predicate
   eagerly on each element in the parameter pack.

2. "My Logicals are in fact just booleans", since you provide them as `bool`s
   to the sequence.

Then, the implementation of `all_of` for `integer_list` could be optimized 
using whatever technique internally -- not the case right now, but trivial 
to implement.

> > > Pair datatype:
> > > --------------
> > > 
> > > Why duplicate std::pair?
> > 
> > For the same reason as `std::integral_constant`; operators.
> 
> Which operators?  I don't see any documented.  There are the first and
> second methods which perhaps can be found by ADL, but that hardly seems like
> a reasonable justification for making another pair type.

You can compare pairs using `==` and `!=`. If their elements are compile-time
comparable, you get back a `hana::bool_<>` instead of a straight `bool`. 
Hence, the `==` for `std::pair` and `hana::pair` is not the same, and we 
need to provide our own pair if we want to make this possible. The operators
supported by each data type will be documented.

> > 
> > > Alternatively, why duplicate list?
> > >
> > > Perhaps list should just define first and second as well?
> > >
> > > Product type class:
> > > ----------------
> > > 
> > > Why isn't a 2-element List, a 2-element std::tuple, etc. an instance?
> > 
> > `hana::list`, `std::tuple` and friends can't be made an instance of the 
> > `Product` type class because they would not satisfy its laws.
> 
> From my reading of the description of the Product type class laws, the
> problem you are referring to is the uniqueness requirement on the function
> "make": for a tuple, you could add more than two elements, with the extra
> elements containing arbitrary unused values.

Exactly.

> However, I don't see any practical reason why it is useful to have a
> separate Product type from a Tuple type.  Potentially, you could document
> that first and second are only valid for 2-element tuples, and make them
> fail for tuples with more than 2 elements.  However, particularly since we
> are just talking about metaprogramming, it seems letting them work for any
> tuple would be better.

There are a couple of reasons why I think Product should stay as it is:

1. If there was no Product type class, how would you interact with std::pair?
   It sure does not make sense to make std::pair an Iterable; how would you 
   implement `tail`?

2. The current Product type class does not provide any instances besides 
   Comparable. The uniqueness requirement makes it possible to provide 
   many more useful instances. What you propose here is to make `first`
   and `second` methods of List or Iterable. However, the instances that
   we can provide for Products might not be the same as those for List or 
   Iterable. In other words, it is useful to limit the "power" of the Product
   type class because it gives us stronger guarantees on its instances.

3. If we provide `first` and `second` for Iterables, why not provide `third`?

4. Product represents a category-theoretical product, which is the most 
   general way of representing a "std::pair". I find this a neat abstraction,
   but of course you could argue that this is subjective.

> [...]
>
> > > What about get<N>, get<N,M> accessors? I understand these can be defined
> > > in terms of the other methods, but clearly they are useful on their own.
> > 
> > For `get<N>`, I'll provide an helper method `at_c<N>(iterable)`. I don't 
> > understand what you mean by `get<N, M>` though. What does `get<N, M>` do?
> 
> Perhaps get_range would be a better name.  The idea would be to return a
> sequence (get<N>, get<N+1>, ..., get<M-1>).

Oh, now I see. I would call it `slice(sequence, from, to)`, and I would 
provide a `slice_c<from, to>(sequence)` version for convenience. I agree
that `slice` is a notable omission in the interface; I'll find out the 
most general type class where it can be implemented and add it when I have
time.

Thank you,
Louis