Jul 29, 2014; 3:04am Niall Douglas Niall Douglas On 28 Jul 2014 at 23:03, Edward Diener wrote:
But I do not understand from your documentation how your library relates to Boost MPL. The Boost MPL library is about manipulating and creating types at compile time, and creating logic paths again at compile time to manipulate types. All of this is encapulated by the MPL's notion of metafunctions to do compile-time programming. But I cannot get from your documentation any of the MPL equivalence of how any of this is done with your library. Is your library meant to duplicate/replace this MPL functionality in some way ? Or is it meant to do something else entirely not related to compile-time programming ?
I am only asking this because I had been told that your library is at the the least a replacement for MPL compile-time type manipulation functionality using C++11 on up.
I think a table with MPL98 forms on one side and Hana equivalents on the other would be an enormous help with the learning curve.
+1
Also, regarding formal review, I personally would feel uncomfortable accepting a library that only works with a single version of clang. I would feel much happier if you got trunk GCC working, even if that means workarounds.
-1 I would disagree. Boost has always required conformity with the latest C++ standard - current compilers be damned. Of course a number of libraries don't make much sense if they're not widely compilable and those authors have accommodated this. But a library such as this doesn't require such a wide compatibility to be useful. No one is going to rip out the mpl in a current library and replace it with hana. A newer app or library will (should) be using a current compilers and just hana from the start. So I think any requirement/request support some older compiler is needlessly burdensome and not worth the effort. Were hana to get accepted, it wouldn't appear in boost for at least a year and by that time C++14 should be available to anyone who want's to depend upon it.
I'd also like to see unit testing that verified that the current compiler being tested has a time and space benchmark curve matching what is expected. It is too easy for code to slip in or the compilers themselves to gain a bug which creates pathological metaprogramming performance. Better to have Travis CI trap that for you than head scratching and surprises later.
I would also like to see a test dashboard of some sort implemented. Especially since it's unclear which compilers can compile this thing.
I'd like to see some mention in the docs of how to use Hana with that metaprogramming debugger from that German fellow. He presented at a C++ Now.
lol - well there's lot's of things I'd like to see - but I think it's not a great idea to request/require some feature/support which depends upon something that isn't in boost and might require significant work to add. Let's make it work before we make it better. Jul 29, 2014; 9:10am Gonzalo BG Gonzalo BG wrote
The documentation is awesome, thanks! I liked the inline discussions that relate the library with Fusion and MPL, and in particular your use of variable templates (e.g. type<>).
awesome is way too generous. needs work. On Tue, Jul 29, 2014 at 10:02 AM, Louis Dionne wrote:
Is it mandatory for a Boost library to have BoostBook documentation? I'd like to stay as mainstream as possible in the tools I use and reduce the number of steps in the build/documentation process for the sake of simplicity. Is there a gain in generating the documentation in BoostBook?
It's not mandatory as far as I know either. Boost documentation is all over the place - from terrible to incredible. And documentation tools have evolved. Library authors haven't often migrated tools once the documentation is done. You DOxygen is a lot better than most I've seen. Misc notes regarding boost documentation. a) In the beginning, boost documentation was just html - a lot of still is just that - e.g. serialization library. b) Then came along BoostBook. Very attractive because it decoupled documentation content from the formatting which allows the creation of PDF and HTML from the same "source". It was on the DocBook "wave" and seemed the way of the future. The tool chain was a pain to setup (and still likely is), but once, set up works pretty well. c) But BoostBook was a pain to edit - then came along QuickBook which defined it's own markup (yet another one!) but produced DocBook source. This addressed the BoostBook editing pain but left the BoostBook advantages. The first workable combination which addressed most needs. d) Some libraries (e.g Geometry, Units) have incorporate DOxygen into this mix due the convenience of including the reference information along with the code. Basically this amounts to a poor man's literate programming system. This is a lot easier for the programmer than trying to maintain two separate markups. e) Somewhere along the line Eric Niebler, let lose an email along the lines of "I can't stand it any more" criticizing boost documentation. Nothing much came of it, but it did affect me and convinced me that what we needed was more formal usage of C++ concepts and requirement that new libraries implement and document them where appropriate. I've been flogging this when/where I can - most recently in the Boost Incubator pages. So far, I haven't made much head way yet, but I'm only 66 so this won't go away for some time yet. Looking at your documentation, I realize now that you've implemented C++ concepts under the name TypeClasses (sounds vaguely familiar from the 20 times I read the haskel book trying to figure out what a monad is). And you have fairly extensive information about what TypeClass means - it means C++ concept / type requirement. I would have much preferred that you had explicitly used boost concept check library. I don't know if your code actually checks the concepts. And I have questions about particular concepts: e.g. Searchable - as opposed to more basic traits - we'll arm wrestle over that later. Given that boost has had no explicit requirements for documentation toolset it would be unfair to start imposing them ex-post facto. So I would say if you can get the content of the documentation to pass the review - we'd could live with your DOxygen version - even though I personally don't like it. So the more I look at this the more I like and the more work I think it needs. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Re-GSoC-Boost-Hana-Formal-review-request-... Sent from the Boost - Dev mailing list archive at Nabble.com.