Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-07-29 18:23:27
Robert Ramey <ramey <at> rrsd.com> writes:
> >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
> 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
> So the more I look at this the more I like and the more work I think it
Thanks for the comments!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk