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