Re: [boost] [GSoC] [Boost.Hana] Formal review request

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 
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