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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-07-29 16:41:15

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-tp4665622p4665719.html
Sent from the Boost - Dev mailing list archive at Nabble.com.