- Boost - lists.boost.org

[Hana] Review
by Roland Bock 20 Jun '15

20 Jun '15

Hi, Here are my review results: - Whether you believe the library should be accepted into Boost Yes. - Your name Roland Bock - Your knowledge of the problem domain. On the one hand, I do believe to have some knowledge in TMP, being the author of sqlpp11. I have made some minor contributions to early versions of Hana, discussing implementations of type sets and all/any/none. I experimented with the MPL for quite some time before the advent of C++11... On the other hand, I am almost totally blank when it comes to Haskell or Fusion. - What is your evaluation of the library's: * Design Awesome. Using template variables to turn types into objects and then treating types and values the same way in most places is very cool. * Implementation I haven't spent too much time on the implementation. I read code around hana::string and hana::all. It was nicely structured and quite readable. * Documentation Impressive already. With all the input from the reviews coming in, it will become even better. I found navigation/searching a bit awkward sometimes. Personally, I would like more cross links/tables. E.g. functions working with Set (Louis already created an issue on github for this). * Tests To be honest, I did not look at them. * Usefulness We'll see what comes out of it. Which libraries are actually going to use Hana. I'll give it a try with sqlpp11. As others have stated, it might be a bit too much even. BUT, regardless of how many projects will actually use it, Hana will force some compiler teams to go to great lengths to be able to compile the library. It might also become a benchmark in terms of compile time and the number of generated instructions. Also, Hana contains a wealth of design ideas, tricks and knowledge for anybody who needs to solve a particular compile time problem. I am sure that many library authors and other developers will benefit from this Hana being available, maintained and developed within Boost. And Hana has minimal dependencies (just a handful of headers from the standard library). Thus Hana might help to change the impression that many people have of Boost (coming from many established, older Boost libraries): Awesomely cool stuff, but dependencies from all nine levels of hell (aka, you can look, but you better not touch). To sum it up: Usefulness? Very! - Did you attempt to use the library? If so: * Which compiler(s)? clang-3.5.1 * What was the experience? Any problems? As described in an earlier mail: - I tried to use Hana's string UDL (the gcc/clang hack) but failed. Hana is not to blame here, it is rather because of shortcomings in the C++ core language. - I thought about using Hana's all/any/none, but my own versions were proven (by Louis himself) to be outstandingly fast, so no reason to switch - I thought of switching to Hana's compile time sets, but that seemed like a tough thing to do considering that I am using type sets and Hana is using value sets. Louis showed samples from Zach Laine which would make the transition easier. Actually, something like this should be part of the documentation. Maybe it might make sense to have a collection of migration examples (before/after code)? That might not sound very successful, but I think it was: While researching how I could achieve my goals I learned a lot about the library. - How much effort did you put into your evaluation of the review? Several hours of reading and some tests in combination with sqlpp11. Remark on compilers: There was some argument as to whether Boost could contain a library that can only be compiled by one compiler (actually, maybe two in this case). My personal opinion is: Yes, Boost could and should do that if the library complies with a modern version of the C++ standard. Compiler teams take pride in being able to compile boost. If they cannot compile a Boost library, they will try to accomplish that ASAP. This is going to help everyone. It is good to have libraries in Boost that challenge compilers even to the point of breaking one or the other. Trying to work around compiler bugs does not seem right for new libraries. Thanks to Louis for his library and to Glen for managing the review! Best, Roland

2 1

[Hana] Formal Review
by Krzysztof Jusiak 20 Jun '15

20 Jun '15

Hi, Please find my review below. - Whether you believe the library should be accepted into Boost Definitely YES. IMHO, one of the most complete boost proposals. - Your name Krzysztof Jusiak - Your knowledge of the problem domain. I've been using MPL and Fusion for about 6 years in commercial projects, I also have been using C++11 /C++14 template features in open source projects since they become available. I have some experience with Haskell and other functional programming languages. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design Library seems to be very well designed. Used patterns are easy to follow. There is a distinction between algorithms, data types and concepts. The approach is really easy to follow for Haskell programmers, but, on the other hand, C++ influence might be noticed as well. Seems to be very straight forward mix of approaches. * Implementation Source Code: First impression, it's a lot of it! But it's easy to follow. Helpful directory structure makes it much easier to handle. Big thanks for changing the naming as well, `snoc`, `cons` and so on, could have been hard to follow for C++ programmers. Implementation consist of a high quality source code. There are few small things, which are not as straight forward. * a lot of fwd (assume forward declaration files) files have implementation inside, which is a bit confusing * a bit annoying `#ifdef BOOST_HANA_DOXYGEN_INVOKED` all over the source code Performance: I have to admit, I really appreciate the library handled this topic. MPL/Fusion, although, very useful are really hard to introduce in commercial projects in the large scale. I do remember using Boost.MSM for a bit, but the company had to give up on it, because having a transition table with more than 200 entries wasn't easy to deal with, to say at least. Having sad that, I think Hana can still improve the compilation times. I didn't even bother to compare it to MPL or Fusion, because there is no comparison there, but with C++ template tricks there is. 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? 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. 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. Tested error message: https://gist.github.com/krzysztof-jusiak/bfc51747d083e140772d 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. 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? * 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`. 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. * 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. Would be great to have CI tests for run-time performance. I have seen charts, but the build could break when performance degradation occurred. * 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 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. I also went through all the source code/documentation/examples as well as played with the library. Thanks Louis for a great library! Kris

4 6

[type_traits] Another big update in develop
by John Maddock 20 Jun '15

20 Jun '15

Just a heads up in case it causes any issues: type_traits has had another big update in develop - added several new traits is_constructible, is_assignable etc which were needed to fix bugs in other traits - and changed most of the has_nothrow and has_trivial traits to make use of these. Also added more test cases to cover the issues where these were defective before. Please do let me know if you spot any unexpected breakages. John.

3 6

[hana] some notes, not a review
by Phil Endecott 20 Jun '15

20 Jun '15

Dear All, I have just a couple of notes about Hana; this does not constitute a review: Firstly, as I understand it Hana believes that it can replace much or all of what Fusion and MPL provide with a superior alternative. If that is the case, I suggest that the docs should not start out by describing Hana with reference to those libraries. At present, it would seem that in order to understand what Hana can do for me, I need to first learn at least a little about those other libraries - and then the Hana docs tell me how it compares to them. This might not be a bad thing in the context of docs for this review, but for "end user" documentation it should stand alone. Secondly, we're moving towards a future where a lot of what previously required TMP can now be done using "regular" C++ code qualified with constexpr. I've just replaced a fair chunk of my crufty old TMP code with constexpr and it is like a breath of fresh air. Against that background, it might be worthwhile to structure your examples by showing what Hana (and TMP in general, perhaps) can do that constexpr cannot do, i.e. start with an example using constexpr and extend it to add features not possible with constexpr. Regards, Phil.

6 6

Help with the wandbox online C++ compiler REST API please
by Niall Douglas 19 Jun '15

19 Jun '15

Dear Boost, I've been trying to get Krzysztof's wandbox script turning into a generic set of reusable tools for the Best Practices Handbook (specifically some Python which will generate a standalone single header include from any library, and generic scripting which can reduce that single header include to the smallest possible representation), but I have a problem which I have failed to surmount, so any advice most gratefully received: ned@jenkins64:~/boost.afio$ ./send_to_wandbox.sh + json_wandbox send_to_wandbox.cpp afio_single_include.hpp + echo -e -n '{ "code" : ' + json_escape send_to_wandbox.cpp + cat send_to_wandbox.cpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e -n ', "codes": [ { "file": "afio_single_include.hpp", "code": ' + json_escape afio_single_include.hpp + cat afio_single_include.hpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e '}], "options": "warning,boost-1.58,c++14", "compiler": "clang-head", "save": true }' + curl -v -F json_file=(a)json_input.json http://melpon.org/wandbox/api/compile.json * Hostname was NOT found in DNS cache * Trying 49.212.130.73... * Connected to melpon.org (49.212.130.73) port 80 (#0) > POST /wandbox/api/compile.json HTTP/1.1 > User-Agent: curl/7.35.0 > Host: melpon.org > Accept: */* > Content-Length: 243073 > Expect: 100-continue > Content-Type: multipart/form-data; boundary=------------------------c58a2396982a31f8 > < HTTP/1.1 100 Continue < HTTP/1.1 500 Internal Server Error * Server nginx/1.9.0 is not blacklisted < Server: nginx/1.9.0 < Date: Thu, 18 Jun 2015 23:56:48 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Status: 500 Internal Server Error < X-Powered-By: CppCMS/1.0.4 * HTTP error before end of send, stop sending < <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>500 — Internal Server Error</title> </head> <body> <h1>500 — Internal Server Error</h1> </body> </html> * Closing connection 0 + [[ '' != '' ]] + echo ned@jenkins64:~/boost.afio$ Whatever I do, I get Internal Server Error from wandbox. Yet copying and pasting the files manually into the web UI works as expected. I am stumped. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

[Better Enums] Non-integral underlying types
by Anton Bachin 18 Jun '15

18 Jun '15

About a week ago, I generalized Better Enums somewhat to accept non-integral underlying types, with some conditions and restrictions. I’d like to ask for comments/opinions/ideas on this feature. I made a little write-up on it [1], but I will summarize here as well. The write-up is a superset of the content of this message, so don’t read the message if you click the link :) If you have a literal type “foo”, you can do: ENUM(SomeEnum, foo, A, B = 2, C = foo(…)) SomeEnum value = SomeEnum::A; switch(value) { case SomeEnum::A: // … case SomeEnum::B: // … case SomeEnum::C: // ... } The switch above can have its cases checked for exhaustiveness by the compiler. Also, “value” above behaves like a “container” for one value of type foo, whose members can be accessed using operator ->. So, basically, you can have enumerated, reasonably type-safe sets of arbitrary literal types. The catch is that you have to provide an invertible mapping from foo into some underlying integral type, which mapping is declared either by equipping foo with the right constructor and conversion operator, or specializing a traits template. I would love to make a default implementation for this mapping, but it seems like I need to achieve the effect of a reinterpret_cast at compile time, and I haven’t been able to do so. [1]: http://aantron.github.io/better-enums/GeneralUnderlyingTypes.html

1 0

Making lots of compile FAIL tests
by Paul A. Bristow 18 Jun '15

18 Jun '15

I've started to devise some tests to ensure that things that really should not compile, do in fact compile-fail. So far I've produced a few files with a single statement that should fail inside a int main(){}. But it's looking at though it will get pretty tedious pretty soon :-( (I see for example that Boost.Multiprecision has some 50-ish compile_fail items) Is there some slicker way of doing this? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 3

Re: [boost] [Boost-announce] [Boost] [Hana] Formal review for Hana next week (June 10th)
by Glen Fernandes 17 Jun '15

17 Jun '15

[Correction: 10th June is a Wednesdsay, not Monday.] Dear Boost community, The formal review of Louis Dionne's Hana library starts Wednesday, 10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher.[1] Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? [1] A note for Windows users: As mentioned, Hana requires a C++14 conforming compiler. If you would like to try it, a VM with Linux and clang 3.5 is a fairly painless option. Some users have also reported success with using Clang 3.5 on Windows. If you would like assistance configuring the former option, feel free to reach out to us for this. Best, Glen

4 4

[Hana] Migrating sqlpp11 to Hana (hypothetically)
by Roland Bock 17 Jun '15

17 Jun '15

Hi Louis, First of all: Hats off to you, your library and the documentation! I wanted to play with Hana for quite some time now. The review certainly offers a good reason to do so :-) Here's my test project: In sqlpp11 [1], lets assume I wanted to replace my own implementations of * compile time strings * type sets * functions like any/all/none with something from Hana. _Compile__time strings:_ This one seems easy. There probably won't be a C++14 version of sqlpp11, but there will be a C++17 version, hopefully allowing me to use the string literal without relying on a non-standard compiler extension. This is what I currently have [2]: struct _alias_t { static constexpr const char _literal[] = "delta"; using _name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>; }; This is what I would like to do: struct _alias_t { using _name_t = decltype("delta"_s); }; But the whole thing is in a header. * I do not want to "using namespace ::boost::hana::literals" at top-level or in one of the namespaces in the header. * Neither one of the following lines is valid: o using _name_t = decltype(::boost::hana::operator"_s"("delta")); o using _name_t = decltype("delta"::boost::hana::literals::operator"_s"); o using _name_t = decltype("delta"::boost::hana::literals::operator""_s); Is there a valid version? Obviously, I would also be happy with something like using _name_t = decltype(ct_string("delta")); * I also cannot use the BOOST_HANA_STRING macro, btw, because that would be a lambda in a decltype... I want to gradually migrate to Hana, so I'd really like to use a type here, not a variable. But I could not even use a variable, because the following does not compile (clang-3.5.1) struct A { static constexpr auto hana_name = BOOST_HANA_STRING("cheesecake"); }; Any hints? _ _ _type sets:_ Currently I store a bunch of types in type sets to do all kinds of tests at compile time. My type set code will need some cleanup or replacement one fine day. Hana to the rescue... Er, wait a second. There is no type set, or is there? There is a set for objects (which might represent types). Replacing all those types with objects would take some time, but I could live with that, I guess. But then I would have to replace all my type_sets (which are types themselves) with static constexpr objects, which use tons of constexpr template variables. And there are other constructs which use the types I now have replaced with objects. So I would have to adjust them, too, probably turning even more types into objects. Can I be sure (given today's compilers) that all these objects stay away from the generated binary? Also, I did not find some of the methods I would expect for sets: * Create a joined set * Create an intersect set * Create a difference set * Test if two sets are disjunct * Test if A is a subset of B, no, strike that, just found it in Searchable I probably could create the methods above with just a few lines of code using the available functions. But it would be convenient to have them available, of course (or did I just miss them?). By the way, I guess it would be easy for you to compile a list of available methods for each type, e.g. Set. Such a mini-index would be quite helpful IMO. _any/all/none: _Quite a bit of code is tuned to stuff like std::is_same: a type that contains a value (true or false). My current versions of any/all/none work like that, too. If I wanted to get rid of my own versions, could I use a drop-in from hana? Or would I have to write something like template<bool... B> struct my_all { static constexpr bool value = ::boost::hana::all(::boost::hana::make_tuple(B...)); }; ? _Intermediate summary:_ * I am not sure if I could replace my current compile-time string yet * I would like to have a few more convenience methods for Set. * It seems to me like if I wanted to use Hana, I should switch to Hana-style completely. Otherwise it will just be a weird mixture. Best, Roland [1]: https://github.com/rbock/sqlpp11 [2]: https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17

4 9

[Boost] [Hana] Announcing Hana's formal review next week (June 10th)
by Fletcher, John P 17 Jun '15

17 Jun '15

Here is my review and some comments. > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost Yes please > - Your name John Fletcher > - Your knowledge of the problem domain. I have been working for some years on functional programming in C++. This is mainly run time work, but it inevitably has involved a lot of work on compile time issues as well. I am also involved in the maintenance of Boost Phoenix. Currently I mainly work to be C++03 compatible, but have done work on C++11 variadics. I am learning from this review how some of the features of C++14 can be deployed to advantage. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have not dug into the Hana code. Instead I have been attempting to adapt its code to work with some of my current examples. It seems to me to be consistent in its approach. > * Implementation I have not found any problems at all with the implementation. > * Documentation It is not always clear exactly which headers are needed for any given example from the manual. It is necessary to look at the example codes. I would like more information about some topics, e.g. monads and comonads. * Tests I have been adapting some of the tests to run with other codes. In particular I have been working with Boost Phoenix and Boost Bimap without any problems once the namespaces are adjusted. * Usefulness I think it is a very useful code for someone attempting to implement a higher level library. There are several things which can be done very easily with it and I am only scratching the surface at the moment. One example is to be able to detect a member function name() in a struct: auto has_name = hana::is_valid([](auto&& obj) -> decltype(obj.name()) { }); and then to be able to print the name if it is present, or do something sensible. // I want to output the name from name() if it is present. template <typename F> std::string print_name(F const& f) { if (has_name(f)) std::cout << "has_name(f) true : "; else std::cout << "has_name(f) false : "; return hana::if_(has_name(f), [](auto& x) { return x.name(); }, [](auto& x) { return std::string("no_name"); } )(f); } > - Did you attempt to use the library? YES > If so: > * Which compiler(s)? Clang 3.5 and 3.6 with libc++ running on Ubuntu 12.04 > * What was the experience? Any problems? No > - How much effort did you put into your evaluation of the review? I have spent some hours implementing examples and running them. John Fletcher _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1