[boost] [hana] Review

Subject: [boost] [hana] Review
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2015-06-23 09:03:09

This is a somewhat perfunctory review of Hana, because I wanted to get
something in before the end of the review period.

I have submitted a few issues on GitHub, for minor things that need not
be repeated here.  Below are the things I found that might warrant more
discussion.

- Whether you believe the library should be accepted into Boost
  * Conditions for acceptance

Yes it should.  No specific conditions.

- Your name

John Bytheway

- Your knowledge of the problem domain.

User of TMP for years.  Once wrote a source-to-source translator to help
me write MPL programs because it was prohibitively difficult to write
them correctly by hand.

- 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).

  * 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.  How should
I know these things?

(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)

  * Tests

Did not look.

  * Usefulness

Very, although not useful for me personally until I decide to bite the
ABI-breaking bullet and recompile all my code in gcc 5.x with the new
libstdc++.

The biggest risk I see is MSVC support.  Microsoft seem to be much more
standards-gung-ho than they once were, so I hope it won't take too much
longer before we see support.  But I do encourage Louis to be wary of
taking advantage of any new language features (e.g. a potential change
in C++17 lambdas-in-unevaluated-contexts rules, or the compiler
extension for compile-time string literals) lest it delay MSVC support.

- Did you attempt to use the library? If so:
  * Which compiler(s)

clang 3.6.1

  * What was the experience? Any problems?

I played around a bit, mostly with a view to finding out how bad the
compiler errors are when things go wrong.  The results were promising.

I went looking for some code of mine to try porting to Hana, and got
sidetracked by one difficulty.  The first project I came across using
Boost.Fusion was passing a lot of fusion::vectors across function
interfaces, but the vector types were specific and the functions not
defined in headers.  Hana's tuple cannot easily be used in this way
since the type is unspecified.  I don't think this is a problem, because
(a) that code was just poorly written and ought instead to be using
adapted structs, which Hana does support, and (b) I can use Hana
algorithms with Fusion's tuples anyway.

- How much effort did you put into your evaluation of the review?

A few hours reading and playing.

Thanks very much to Louis for his effort.  I look forward to being able
to use Hana in the not-too-distant future, and I'll make GitHub issues
for any more things I discover in my testing.

John