[boost] [Hana] Formal Review

Subject: [boost] [Hana] Formal Review
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2015-06-18 09:34:23

Hi,

Please find my review below.

- Whether you believe the library should be accepted into Boost
Definitely YES. IMHO, one of the most complete boost proposals.

- Your name
Krzysztof Jusiak

- Your knowledge of the problem domain.
I've been using MPL and Fusion for about 6 years in commercial projects, I
also have been using C++11 /C++14 template features in open source projects
since they become available. I have some experience with Haskell and other
functional programming languages.

You are strongly encouraged to also provide additional information:
- What is your evaluation of the library's:

  * Design
    Library seems to be very well designed. Used patterns are easy to
follow.
    There is a distinction between algorithms, data types and concepts. The
    approach is really easy to follow for Haskell programmers, but, on the
    other hand, C++ influence might be noticed as well. Seems to be very
straight
    forward mix of approaches.

  * Implementation
      Source Code:
        First impression, it's a lot of it! But it's easy to follow.
Helpful directory
        structure makes it much easier to handle. Big thanks for changing
the naming as well,
        `snoc`, `cons` and so on, could have been hard to follow for C++
programmers.
        Implementation consist of a high quality source code. There are few
        small things, which are not as straight forward.
            * a lot of fwd (assume forward declaration files) files have
             implementation inside, which is a bit confusing
            * a bit annoying `#ifdef BOOST_HANA_DOXYGEN_INVOKED` all over
the
              source code

      Performance:
        I have to admit, I really appreciate the library handled
        this topic. MPL/Fusion, although, very useful are really hard to
        introduce in commercial projects in the large scale. I do remember
using
        Boost.MSM for a bit, but the company had to give up on it, because
        having a transition table with more than 200 entries wasn't easy to
        deal with, to say at least. Having sad that, I think Hana can still
        improve the compilation times. I didn't even bother to compare it to
        MPL or Fusion, because there is no comparison there, but with C++
        template tricks there is.

        Compilation time:
            So I have written simple example to compare `Hana Map` and `C++
            Tricks Map`. Please notice, I compared map with 1000 entries!
            Hehehe, can anyone imagine that with MPL or Fusion?

            Results are here:
                tricks_map:

https://gist.github.com/krzysztof-jusiak/cb6633d6c11572c33928
                    0m0.095s

                hana_map:

https://gist.github.com/krzysztof-jusiak/949d3916d84c466b80c5
                    0m11.105s

            So, Hana seems to be much slower, but still not really slow.
It's
            not hours, just a few seconds, which IMHO, it's a huge
improvement
            already.

        run-time:
            Haven't checked this part as deeply.

        Diagnostic Messages:
            Really popular topic recently and Hana made a huge progress with
            it as well. Concepts helps a lot, but, unfortunately, there is
            always a call stack following the error message. Sometimes, such
            approach is desired, but would be great not to see all Hana's
            internals, especially with recursive algorithms.
                Tested error message:

https://gist.github.com/krzysztof-jusiak/bfc51747d083e140772d

            I also had some issue, when some include was missing.
            Compilation was fine, but the computation was run-time only.
Would
            be great to somehow handle this problem. It's really tricky to
            understand, why it doesn't work as expected.

        Debugging:
            Guess, in this matter, there is still no much progress. I tried
            Hana with MetaShell and TempLight, but, although, it was way
better
            experience, it still was hard to debug the library. What about
            run-time algorithms? I haven't checked how hard it is to debug
            them, but I suspect it will be the same story as with STL,
unless
            some magic is happening in HANA under the hood?

  * Documentation
        Documentation is really impressive. Honestly, love the search
button!
        Would like to see more copy/paste examples tho. I'm really inpatient
        sometimes and when have to find part of the example at one place and
        figure out includes I do get easily annoyed. Related to that, would
be
        great to always see which file has to be included for anything which
        is not included by `boost/hana.hpp`. As already mentioned, would be
        better to use hana::...  instead of having an assumption for `using
        namespace boost::hana`. I would also add some tutorial for less
        experienced users with explanations what the monad is and how
        functional programming concepts are applied in Hana.

  * Tests
        Impressive unit tests collection. Unfortunately, they are not that
easy to
        follow. Approach like:
            // check a
            {
            }

            // check b
            {
            }
        is not the best and I would encourage to add separate tests for both
        cases.

        Would be great to have CI tests for run-time performance. I have
seen
        charts, but the build could break when performance degradation
        occurred.

  * Usefulness
        With C++11/C++14/C++17 template metaprogramming become a lot easier
and a a lot of stuff might be written without need of
        TMP library at all. However, Hana is more than that, and I find it
very useful. MPL and Fusions are/were extremely helpful and Hana is a huge
step forward.
        *Frankly speaking, I would replace `std::tuple` with `hana::tuple`
straight away.*

- Did you attempt to use the library? If so:
  * Which compiler(s)
     Clang 3.6/Clang 3.7 + libc++ (on linux/mac/windows) -> worked fine
     Tried on GCC-5.1 (on linux) without any success -> didn't link, but
this issue is well known already
     Tried on MSVC 2015-RC (just for a sake of trying -> didn't work ;)

  * What was the experience? Any problems?
    I haven't experienced any blockers whilst trying the library. The only
    problem for me, is lack of support for MSVC. A lot of commercial
projects
    requires MSVC as much as Clang/GCC.

- How much effort did you put into your evaluation of the review?
    I have been watching/trying Hana since April last year when I started
to implement C++14 version of proposed boost.di library.
    I tried to re-implement C++03 version using Hana, but back then, Hana
was crashing very often. Therefore, I decided to use plain C++14 features
instead.
    I also went through all the source code/documentation/examples as well
as played with the library.

Thanks Louis for a great library!

Kris