Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-18 14:20:15

David Sankel <camior <at> gmail.com> writes:

>
> On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes <glen.fernandes <at> gmail.com>
> wrote:
>
> [...]
>
> > You are strongly encouraged to also provide additional information:
> > - What is your evaluation of the library's:
> >   * Design
> >
>
> The core technique of combining value and type expressions is solid and
> makes metaprogramming easier and, as a bonus, improves compilation speeds.

I'd just like to point out that representing types as value is not what makes
compilation faster. It is actually the oposite: representing type-level
computations at the type-level is indeed faster, since the compiler has less
work to do.

What makes Hana faster than Fusion/MPL is the usage of modern C++14 techniques
and also a design built around the compiler's execution model rather than the
machine's execution model (like the STL/Fusion/MPL with iterators).

For pure type-level computations (which are mostly a myth in C++14, because
you usually don't need them that much), the fastest way to go would be to use
something like the MPL11 I presented in 2014, or Meta (if it's implementation
is clever enough). Basically, a MPL (pure-type), but using C++11/14 techniques.
However, then you're back to the great fun of writing type-level computations
like you did in C++03.

My gamble with Hana is that for the very few times you actually need type-level
computations, taking a small compile-time hit is worth the expressiveness gain
and the ease of interfacing with your actual heterogeneous runtime code
(written also with Hana), which is what's important at the end of the day.

> My one question, as I read though the implementation, is "can the core
> benefits of this library be achived with a simpler 'light' version of this
> implementation?". While I appreciate the attempt to encode a Haskell-style
> typeclass hierarchy, I feel like that is not the core competency of hana
> and should be a separate library and discussion. As it is, this is a 32k
> header mega library. I'd prefer several small, highly-targeted,
> highly-composable libraries.

Yes, it would be possible. That would mean (non exhaustively):

Pros:
- No conceptual overhead (it would dumb tuples + algorithms, nothing else)
- Slightly faster compile times (smaller library)

Cons
- No real separation in concepts. This is the flipside of having no
  conceptual overhead.
- No interoperation with other libraries (STL/Fusion/MPL)
- No (or very little) possibility of extending the library by users.
  Don't even try defining your own sequence, it wouldn't be supported.

Hana advertises itself as a "standard library for metaprogramming". If you
look at Eric's Range library, for example, he also has to define a truckload
of concepts to get this done. My feeling is that in order to do something
_cleanly_, one must sometimes aim for something larger than the strict
minimum that can technically get the job done. That's what I went for.

However, it is clear that for some users doing simple stuff Hana's concepts
will just be annoying. Hence, there is definitely value in a library that
would basically implement Hana's core, but only that. Shooting from the hip,
that would include:

- An efficient tuple implementation (std::tuple usually sucks, sorry)
- Efficient algorithms on this tuple type
- A way to wrap types into values
- Extended integral constants with operators
- Maybe, but just maybe, a compile-time Optional

That could either be a different library (I could consider taking this over
in the future), or splitting Hana in such a way that this Core content can
be accessed without any conceptual/compile-time overhead. However, this is
either a non-trivial redesign of the library or a new library completely,
so it is part of a "future plan".

> >   * Implementation
> >
>
> The code itself looks to be well structured and well documented.
>
> Unfortunately hana only works with one compiler: clang. While I agree that
> Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is
> going too far in the opposite direction. The home page states that boost
> libraries "are intended to be widely useful, and usable across a broad
> spectrum of applications". I've always interpreted that statement to be in
> a practical rather than theoretical sense and I don't think hana meets that
> criteria. Many other Boost authors have made heroic efforts to meet that
> criteria and the reputation of Boost is due, in no small part, to those
> efforts.
>
> I do appreciate the argument that making use of new features encourages
> compiler implementers to implement then. I maintain, however, that this
> isn't Boost's job. Boost provides high quality libraries that the every-day
> Joe C++ developer can benefit from.
>
> That being my position on the issue, my acceptance vote is conditional on
> hana supporting at least two released versions of mainstream compilers.
> Given that gcc support seems pretty close, that shouldn't be hard to
> achieve.

[Be warned, I'm getting slightly emotive below.]

It's not about me, it's about them. Seriously, go look at GCC's or Clang's
bug trackers. Since I seem to be the only user doing "real" stuff with new
C++14 features, I'm also the one finding a lot of the bugs. But of course, I
don't weight much in the balance when paying customers(*) ask for bugs to be
fixed, or when more obvious C++03 bugs appear. The most important thing
stopping Hana from becoming more mature (and higher quality) is the lack of
users and the lack of support from compilers. Both can be fixed
__very quickly__ by entering Boost, or we could also sit back and enjoy the
ride for the next year or so.

(*) I waited for this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719
to be fixed for more than 2 months. The bug was fixed 2 days after someone I
know filed the same bug against RedHat. The dev who fixed the bug worked for
RedHat, and the fix was 2 lines of code in GCC. That could be a coincidence,
but I doubt it. What I'm asking for is not rock solid perfect C++14 support,
but I simply need stuff like this

    int main() {
        [](auto x) -> decltype((void)x) { };
    }

to compile on GCC (try it).

Oh and by the way, if I don't find these bugs now, you will find them
yourself when you use (even trivial) C++14 features in those compilers.
So we're all together in the same boat, except for MSVC users who seem
to enjoy swimming along.

</end rant>

>   * Usefulness
> >
>
> Maybe in a couple years for me. Without VS 2015 support at least, I'm going
> to be waiting a while.
>
> - Did you attempt to use the library?
>
> Yes. Started working through the getting started examples.
>
> > If so:
> >   * Which compiler(s)
> >
>
> clang 3.6.1
>
> >   * What was the experience? Any problems?
> >
>
> Nothing more to add. I filed an issues for all problems encountered and
> they seemed minor.

For the reference of others, the problems are related to the lack of testing
on libstdc++ on Linux. I'm working to fix those errors, and also test on
libstdc++ on Travis.

Thanks a lot for the review, David. I'll try to get your compilation errors
fixed ASAP.

Regards,
Louis