Boost logo

Boost :

Subject: Re: [boost] [Hana] Informal review request
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-03-07 06:32:17

Le 05/03/15 15:41, Louis Dionne a écrit :
> Dear Boost,
> As some may be aware of, I am currently working on a metaprogramming library
> called Hana, with the intention of proposing it for inclusion in Boost. The
> purpose of that library is to act as a toolbox for expressing computations
> on both types (like the MPL) and heterogeneous values (like Fusion). The
> library is built around C++14 idioms and implementation techniques to
> maximize expressiveness and performance.
Hi and thanks in advance for your work.
> I am now requesting feedback from the community, with the intention of asking
> for a formal review in the next months. A similar review was asked for in last
> August. The library has undergone several modifications since then, both to
> address issues raised during the review and for general improvement. Here are
> some issues that were raised during the review and addressed:
> - Usage of names and terms unknown to C++ programmers: Efforts were made to
> make this better, and several functions were renamed (`fmap` is now
> `transform`). When possible, the documentation also uses terms more
> familiar to C++ programmers, like concept instead of "type class".
I'm not sure the use of the term "concept" instead of "type class" is
appropriated (given that the C++ standard is defining concepts in a
different way). Hana "type class" is based, as Concept C++0x, on
signatures. An instance "type" of a "type class" needs a mapping of the
signature. I can live with the term TypeClass. Nevertheless if you don't
want to use it I will suggest you the terms "MappedConcept" or
"SignaturedConcept" instead of "Concept".
> - The order of the arguments to some algorithms was unfortunate for C++. It
> was consistent with Haskell, but it turned out to be cumbersome in C++.
Just for curiosity, could you give some examples of these changes and
why it was cumbersome?
> This is changed in most places.
> - Inability to easily implement individual algorithms: This is fixed, and
> algorithms are now standalone structures using tag-dispatching, almost
> exactly as in Fusion.
Just for curiosity, could you give some examples of these changes and
why it was difficult before the changes?
> - Lack of a good introductory tutorial: A lot of work has gone into improving
> both the tutorial and the reference documentation.

I appreciate what has been done already to improve the tutorial. Next
follows some comments about the design.

DataTypes and TypeClasses
I appreciate what has been done already. I have some trouble with the
"datatype" use. If I understand it correctly, the type you map to a
"type class" is not the type itself but its datatype (which can be the

In Haskell, type classes can be universally quantified or not. E.g. the
"type class" Eq is not universally quantified

class Eq a
`(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool

while the "type class" Functor it is universally quantified

class Functor f where
   fmap :: (a -> b) -> f a -> f b

That means that the instance mapping for Eq is from types (*) and the
instance mapping for Functor is for type constructors having one
parameter (* ->*).

Let me show the instance mapping for Either in Haskell

(Eq a, Eq b) => Eq (Either a b)

Functor (Either a)

Note the difference. In the first case the instance is Either a b. In
the second it is Either a.

I don't see this nuance in your library. The datatype of
left<A>/right<B> is Either, and the instance of Comparable and Functor
is always Either. BTW, I'm missing a type either<A,B> see below

I'm wondering if the library shouldn't make this difference and make
either<A,B> be an instance of Comparable and either<A,_> be an instance
of Functor, where either<A,_> stands for the universal type constructor
having a parameter.

Compile-time error reporting

I would expect that the library provide some king of "TypeClass" check
use (As Eric's Range library does with Concepts) so that the compile
time errors are more explicit.

Unnamed data types
I'm missing, between other, the concrete types _either<A,B> and
_maybe<T>, as we have _pair<A,B>. How the user can declare a structure
having data members with these data types?

About a pure type meta programming sub-library Hana/Meta

While I agree that it is good to be able to define the algorithms only
once for types and values, I find the syntax cumbersome when the user
wants only to work at the meta-programming level.

I wonder if the library shouldn't contain a sublibrary Hana/Meta that
defines in a meta namespace all the algorithms/types that work directly
on types and integral constants.

Instead of defining a hana::tuple_t, I suggest to define it in
meta::tuple that works only with types and a meta::transform that works
only on types.

This will allow to write ([1])

     meta::transform<meta:: tuple<int, char const, void>,
std::add_pointer>{} ==
     meta::tuple<int*, char const*, void*>{}
, "");

instead of

     hana::transform(hana::tuple_t<int, char const, void>,
hana::metafunction<std::add_pointer>) ==
     hana::tuple_t<int*, char const*, void*>
, "");

The definition of meta::transform will just do the steps 2 and 3 of the
process you describe:

 1. Wrap the types with |type<...>| so they become values
 2. Apply whatever type transformation |F| by using |metafunction<F>|
 3. Unwrap the result with |decltype(...)::type|

namespace meta {
   template <class Tuple, class F>
   using transform = |decltype(|hana::transform(Tuple{},

An additional advantage of having this Meta library is that it can be
defined using just a C++11 compiler, as it is done in Eric's Meta library.


[1] the name could be also meta::list.

Boost list run by bdawes at, gregod at, cpdaniel at, john at