[boost] [Hana] Formal review

Subject: [boost] [Hana] Formal review
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-06-21 20:53:11

Dear all,

Following is my review of Hana.

   - Do you think the library should be accepted as a Boost library? Be
   sure to say this explicitly so that your other comments don't obscure your
   overall opinion.

Yes, absolutely, but please read on.

   - Are you knowledgeable about the problem domain?

I've been playing with metaprogramming as a hobby since 2011 when I first
came across Boost.MPL. I experimented with a library that implements the
unification algorithm at compile time using Boost.MPL for a long time, on
and off, and recently I've decided giving a shot at my own implementation
of a C++11 version of Boost.MPL.

   - What is your evaluation of the design?

The design seems to be very general and abstract, based on
formal mathematical concepts. I've had my dose of FP through SML and lisp,
however I've never dug deep into category theory, so I won't venture into
judging the way these abstract concepts were translated to C++, but all
looks sound to me.

I'm very fond of the way type computations are carried out by value through
the use of type<> and decltype(). Such an ingenious simplicity. Once one
gets it, one realizes how beautifully it merges value and type computations
into one.

I also like very much the design of compile time constants, their custom _c
suffix and operators. To me, that is material for standardization.

I would like to point out however, that from the point of view of someone
who has basically solely done C++ his entire life, just like myself, Hana
can look *very* unfamiliar. I understand it is mostly my fault for not
properly having learnt FP before, however I believe I'm not alone among
average C++ programmers, so I fear this could prevent many potential users
from adopting Hana, simply because one tends to stick to things that look
familiar to one.

Now I'm not sure that is any easy way around this unfamiliarity. I've seen
others pointing out that names could better reproduce the C++ standard
library (to what I agree) and perhaps that's indeed all one could do to
tighten the gap that separates Hana from mainstream C++ libraries. At any
rate, I just felt I should stress this point, to make sure it is not
underestimated.

   - What is your evaluation of the implementation?

I've just briefly peeked at the code base out of curiosity and it looks
pretty clean and organized.
The use of global function objects however intrigues me, why not free
functions?
I've also found myself stumbling on variable templates. Perhaps that's just
me, but really I find they make everything so cryptic. Anyways, I guess it's
not Hana's fault to make arguably good use of something that is part of the
language.

   - What is your evaluation of the documentation?

I find myself blindly using the search button in hope to find whatever I'm
looking for more often than I'd rather do, but perhaps it's just a matter
of getting used to how the documentation is organized.

One thing I'd like to see improved is the alphabetical index. I'd expect it
to be thorough, but at least "is_a" is missing, so I assume a rationale
exists to decide what goes there? I think it would be better to list
everything exhaustively, so users may rely on the browser's find tool to
explore the library.

   - What is your evaluation of the potential usefulness of the library?

At first I was afraid Hana were too academical and abstract to be a good
tool for getting down to business, but after playing with it a little bit I
can see that, once one gets its design, it does make metaprogramming quite
straightforward.

I believe however that most users will attain to a very limited subset of
functionalities in order to just get their tasks accomplished. So much so,
that I'd strongly advise Hana to be split into one highly specialized tool
for straightforward metaprogramming and another more abstract halve
providing the more generic concepts. This could ease user experience
considerably, reducing the novelty presented by Hana and thus tightening
the gap I've mentioned before.

   - Did you try to use the library? With what compiler? Did you have any
   problems?

Yes on Clang 3.6.1.
I tried to implement the unification algorithm [1] at compile time using
Hana and, though I haven't actually finished, I could see it would
be straightforward.
In fact I gave up on it when I found a bug which prevented the construction
of optional maps, but not too long after I contacted Louis and opened an
issue [2] it seems to have already been fixed on develop branch. I didn't
test the fix myself though.

   - How much effort did you put into your evaluation? A glance? A quick
   reading? In-depth study?

About 4 hours reading the documentation, another 4 hours trying the library
and about 2 hours to write this review.

*Bruno C. O. Dutra*

[1]: https://en.wikipedia.org/wiki/Unification_(computer_science)
[2]: https://github.com/ldionne/hana/issues/149