Re: [boost] [Hana] Announcing Hana's formal review next week (June 10th)

Subject: Re: [boost] [Hana] Announcing Hana's formal review next week (June 10th)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-14 10:16:25

Le 05/06/15 21:18, Glen Fernandes a écrit :
> Dear Boost community,
>
> The formal review of Louis Dionne's Hana library starts Monday, 10th
> June and ends on 24th June.
>
> Hana is a header-only library for C++ metaprogramming that provides
> facilities for computations on both types and values. It provides a
> superset of the functionality provided by Boost.MPL and Boost.Fusion
> but with more expressiveness, faster compilation times, and faster (or
> equal) run times.
> <snip>
> We encourage your participation in this review. At a minimum, kindly
> state:
Here is my mini review. I have created some issues on github. My vote is 
not subject to the result of any of them.
> - Whether you believe the library should be accepted into Boost
Yes, yes and yes. I consider Boost.Hana must be accepted into Boost.
> - Your name
Vicente J. Botet Escriba
> - Your knowledge of the problem domain.
A good knowledge and I have learn a lot more with the work of Louis in 
Hana.
>
> You are strongly encouraged to also provide additional information:
> - What is your evaluation of the library's:
>    * Design
Brilliant, awesome. Seen types as values is a revolutionary design. 
Thanks Louis.

I liked the way the Haskel concepts have been adapted to C++14.

In previous version of the library (I don't know when this has been 
changed), I liked
* type classes,
* the instantiation either directly or when the type is an instance of a 
type class (using the second parameter).
* the minimum definition set and how to inherit from them.
* The split concepts and data_types to make it more evident the distinction.

All this has now disappeared, surely as requested in this ML :(.

Things that I like less are

* the data_type (tag) concept. IMO, what is behind is a type 
constructor. A type constructor is a class that has a nested alias 
template apply to build new types. A class template can also be seen as 
a type constructor by lifting it.

* the fact that the result type of a lot of functions is not a concrete 
type or is not defined.

* the fact that the interface is not typed, the use of auto and lambdas 
everywhere is less informative that a typed interface.

* the Signature as an alternative way to define the interface should be 
documented. I would find more useful to define the signature before the 
description.

* This is a library with a lot of Concepts. It is not easy to find the 
correct name for each of them and each of the functions in the C++ world 
when the concepts come from another language with different history. 
There are some names that I don't like, but I recognize that finding a 
coherent set of names is not easy.

* the fact that all the functions are in the same namespace. This imply 
that we need to find a different name for each function. Making use of 
namespaces for each concept add a freedom degree.

* The functional part has disappeared as there were some overlapping 
with Boost.Fit (We need now Boost.Fit).

* the instantiation either directly or when the type is an instance of a 
type class (using the second parameter).

I'm not yet clear about
* the fact that Hana has reimplemented part of the standard to avoid 
dependencies and improve performances. IMHO, this is not the C++ way, 
but Maybe the C++ standard library should be structured in a different 
way. Maybe the expected modules could help here.

>    * Implementation
I used to inspect the old version. I have less inspected the current one.

I find it quite clear and elegant even if I prefer the architecture of 
the old version.

>
>    * Documentation
Very good tutorial.

The documentation would improve a  lot with a better design rationale 
section.
* What a Concept is and how the map is done.

* What a Tag/datatype is, why do we need it, alternatives, and how all 
this works.

* Naming and order of parameters

* Why and when free functions or member functions are used.

The reference documentation is a little bit confusing for some one used 
to the C++ standard way.
* The terms Concept/Superclass/Methods, ...

* The Signature as an alternative way to define the interface should be 
documented. I would find more useful to define the signature before the 
description.

* A more formal definition of the mappings from concrete type to 
Concepts and the Super classes

Maybe this is enough for Boost, but I would like to see a more C++ 
standard like documentation.

>    * Tests
Not inspected in depth, but it seems well covered.
>    * Usefulness
Very useful.

Even if I have not used it directly, I have taken a lot of ideas from 
his design.
If the announced performances are there, it is clear that Boost.Hana 
will be used more a more by those that can use a C++14 compiler. I'll 
hope adding a dependency on the C++ standard library will not degrade 
the performance so much.

> - Did you attempt to use the library? If so:
No yet.

I will do it as soon as I install the good compiler version.
>    * Which compiler(s)?
>    * What was the experience? Any problems?
> - How much effort did you put into your evaluation of the review?
>
>
Thanks again Louis for this wonderful library.
I would like to see in Boost a similar functional library but this time 
for run-time types.

Vicente