Re: [boost] [Hana] Formal Review

Subject: Re: [boost] [Hana] Formal Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-18 22:27:55

On 6/18/2015 4:11 PM, Louis Dionne wrote:
> 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?

If you build clang targeted for gcc RTL ( not MSVC ) on Windows you can 
use Boost Build with the current clang.jam file by just specifying 
toolset=clang. If you need help doing this just ask.