Re: [boost] [Hana] Formal review for Hana

Subject: Re: [boost] [Hana] Formal review for Hana
From: Kohei Takahashi (flast_at_[hidden])
Date: 2015-06-16 12:15:26

Hi Glen, Louis and all,

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

> - Your name
Kohei Takahashi

> - Your knowledge of the problem domain.
I'm working on maintaining Boost.Fusion.

> You are strongly encouraged to also provide additional information:
> - What is your evaluation of the library's:
>   * Design
Well organized and it shows the great potential of variable templates.
Also purely functional programming excites me, I started to learn Haskell :)

>   * Implementation
Some identifiers, whitch defined under boost::hana, begin with single
underscore (e.g. `_is_a' in core/is_a.hpp). I think (and be afraid) it
will violate [lex.name] p.3 (I referenced n4296) when user use
using-directive (i.e. `using namespace boost::hana;'). Rename or move to
detail namespace might be better, since thouse are documented as
/unspecified-type/.
(I found return type of `make<Tuple>' is not a unspecified-type in the
document. Is this intended?)

>   * Documentation
Well described, but...

  * Should be more clearly about which C++14(11) features are required.
    Most of users assume working with C++98 since all of currently
    released Boost libraries work under C++98. Also, some (proprietary
    or not) vendor might ship customized compiler based on OSS one.
    In such case, users have difficulty in determining usable or not
    since some features are unsupported or dropped. Boost.Config will
    help and depending it is better than self organizing, IMO.

  * It is important, in contrast to Fusion and std::tuple, Data types
    can't modify even its element. Users might use similar to Fusion
    (assgin, tie, ...) because most of the C++ programmers have no
    backend about purely functional programming and immutables and god
    compile error. Also, C++14 constexpr allow to assign, thus
    /constant-expression/ doesn't make sense to describe purely.
    It is the best, describing about it in Introduction section (also
    describing about can't make /tie/ is better).

  * Where is source of documentations? How to generate it?
    It seems to be generated using doxygen, but any of headers don't
    contain its documents.

>   * Tests
I didn't run, but it seems to be enough though.

>   * Usefulness
Since names are similar to haskell, some users might confuse about usage
(e.g. `maybe' v.s. `Optional'), but it's trivial: no worry about that.

> - Did you attempt to use the library? If so:
>   * Which compiler(s)
I tried some tiny code with GCC 5.1.0.

>   * What was the experience? Any problems?
Compiling is much faster than Fusion, Wow!

> - How much effort did you put into your evaluation of the review?
It was bit hard to understand some semantics because I'm not a Haskell
programmer and have no mathmatic backends.

Best,
Kohei