Robert Ramey
[...]
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.
I wanted to do it, but then I could not register on my.cdash.org. After a couple of failed attempts, I resumed to fixing other stuff. I'll try again.
Especially since it's unclear which compilers can compile this thing.
It's very clear which compilers can compile it; only Clang trunk, and you have to ask politely or it segfaults. :)
[...]
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.
Agreed, I'm working on it.
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.
If it's not mandatory, I'd rather spend time making the documentation better than wrestling with a new system to generate it.
[...]
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.
Hana type classes and C++ concepts are _related_, but the resemblance stops here. In terms of functionality, Hana type classes are much closer to the Fusion and MPL tag dispatching systems, but 10x more powerful. Using the ConceptCheck library was out of question for two reasons: - I don't need its functionality - Even if I had needed its functionality, Hana is a core library, a library used to build other libraries. I want to keep the dependencies as low as possible, and I have achieved to depend on nothing at all (right now the standard library isn't even used, but that might change). Here are some reasons for me taking such a radical 0-dependency approach: + The additional work to remove dependencies was almost trivial, it's basically one small header file. + Contrast this with the cyclic dependency problems introduced by the MPL and other core libraries, and I'm glad Hana is standalone. + Every time you include a Boost header, it includes many other headers. That's a sad reality and its the price to pay for portability and reuse, I understand this. However, Hana has like 5k SLOC and it needs to stay small to keep the include times low.
And I have questions about particular concepts: e.g. Searchable - as opposed to more basic traits - we'll arm wrestle over that later.
I'm especially satisfied about that type class; it's not present in Haskell and it makes it possible to search infinite structures by defining only two methods. Those familiar with Haskell will observe that Searchable contains the part of Haskell's Foldable which actually uses laziness.
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.
Thanks for the comments! Louis