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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-29 06:04:04

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.

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.

BTW some of those graphs you had in C++ Now showing time and space 
benchmarks of performance would be really useful in the docs, maybe 
in an Appendix. When MSVC eventually gets good enough that Hana could 
be ported to it (VS2015?) I think it would be fascinating to see the 
differences. I'm sure Microsoft's compiler team would also view Hana 
as an excellent test of future MSVCs, indeed maybe Stephan could have 
Hana used as an internal test of conformance for the team to aim for.

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

Finally, there are ways and means for doxygen docs to automatically 
convert into BoostBook docs. You'll need to investigate those before 
starting a formal review. Tip: look into how Geometry/AFIO does the 
doxygen conversion, it's brittle but it is easier than the others.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/