Re: [boost] [Hana] Formal Review

Subject: Re: [boost] [Hana] Formal Review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-18 16:11:16

Krzysztof Jusiak <krzysztof <at> jusiak.net> writes:

> [...]
>
>         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?

For the record, Hana's Map is not optimized right now. This is the subject
of my GSoC project for this summer. So the performance should be pretty bad.

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

Actually, I think it is very good. Indeed, the current Map implementation is
very dumb and lookup is done by doing a linear search inside a tuple. Doing
a short-circuiting linear search in a 1k element Tuple without busting the
recursion limit is, I think, an achievement by itself. Actually, I have to
check why it works :-). Of course, this does not mean that the Map should
not be optimized: it will, and I expect to match roughly the performance of
a hand-written Map.

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

I think this call stack is desirable, since it allows you to see where
things blew up. Of course, there are a couple of levels of Hana-stuff
in there, but you'll get the exact same thing if you instantiate a STL
algorithm with an improper predicate. The only way to reduce the number
of in-between steps would be to inline Hana's functions by-hand. I think
language support would be needed to get significantly better diagnostics.

Also, if you'll notice, there are only two errors here. One is the actual
error you made in the code, and the other one refers to a call to some
deleted function `apply`. Usually, the compiler would explode and give a
truck of error messages because it tries to continue compiling even after
the error occurs. However, Hana will disable the next call when an error
happens to make these useless messages disappear. That's where the call
to a deleted function comes from.

>                 Tested error message:
>
> https://gist.github.com/krzysztof-jusiak/bfc51747d083e140772d

<aside>
Ahaha! Finally I get this example I was looking for! To all of those that
say "lambdas can't appear in unevaluated contexts because of implementation
difficulties", I now dare say "Bullshit"! If you look at the above example,
you'll notice that a lambda happily appears inside a `decltype(...)`. This
is a Clang glitch (the only one I never reported) that only works in some
specific circumstances, which allows us to have lambdas appear inside
unevaluated contexts. This allows us to write type-level computations
with value syntax inline, without ever needing to create an external
variable.

I want lambdas in unevaluated contexts for C++17. Please.
Also, people, please don't report this bug :-).
</aside>

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

Can you share a link to that example? It would be helpful for me to see
the exact thing so I can try to find a solution.

>
>         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?

If your code compiles and you have a runtime bug, you can debug your code
with a normal runtime debugger, just like you would do with the STL. You'll
have to jump through a lot of function calls however, since heterogeneous
algorithms can (in most cases) only be implemented recursively.

For debugging something that does not compile, I do not have a proper solution,
and I think an external tool is really required. However, since Hana is
functional in nature, it is often possible to extract large chunks of code
and to just cut/paste stuff around to reduce your problem. Since there's no
mutation, it's fairly straightforward. Of course, that is still not very
satisfactory, but the problem is with C++.

>   * 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`.

Ok, I will try to make the examples self-contained. See this issue [1].

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

I think that explaining Monads is out of scope for Hana. What I can do is
provide helpful links to existing tutorials, but I don't want to fall in
the Monad Tutorial Fallacy [2]. I do agree that more extensive examples of
how the functional concepts can be used in the specific context of
metaprogramming would be helpful. I'll try to improve some of the examples
given for Monads/Applicative & al.

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

I would like to modularize the test suite. However, I have two main issues:
- I want to avoid code duplication as much as possible
- I want to reduce the compile-time of the test suite. It is already very long
  to compile, and putting more stuff in the same file helps to reduce this.

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

This is quite sophisticated, but a good suggestion and I would like to have
that in the long term. Added this issue [3].

>
>   * 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

It should now link on GCC trunk, but other errors will pop up. Will try to
fix this. Also, is Clang available on Windows? How so?

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

Hana used to use generic lambdas in its implementations. Since generic lambdas
are a C++14 feature, you can guess that support for them was lacking (even in
Clang). Because there were so many problems, and also because that prevented
the library from being constexpr, I decided to remove lambdas from the
implementation. That's probably why it's more stable right now.

>     I also went through all the source code/documentation/examples as well
> as played with the library.
>
> Thanks Louis for a great library!

Thanks a lot for the review, Krzysztof. Also, I'd like to thank your for
your interest in the library from the beginning and the bug reports you
submitted a while ago. All this was helpful, especially when the library
was at such an early stage.

Regards,
Louis

[1]: https://github.com/ldionne/hana/issues/139
[2]: https://goo.gl/4XX5hc
[3]: https://github.com/ldionne/hana/issues/140