Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-17 17:29:29

Le 17/06/15 21:55, David Sankel a écrit :
> On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes <glen.fernandes_at_[hidden]>
> wrote:
>
>> - Whether you believe the library should be accepted into Boost
>>    * Conditions for acceptance
>>
> Yes, I think it should be accepted into Boost. The one condition is that
> the library works with release versions of at least two different
> mainstream C++ compilers. More on that later...
I understand that we need at least two compilers, but I suppose this 
should be achieved by the time the library would be ready.
>
>> You are strongly encouraged to also provide additional information:
>> - What is your evaluation of the library's:
>>    * Design
>>
> The core technique of combining value and type expressions is solid and
> makes metaprogramming easier and, as a bonus, improves compilation speeds.
>
> My one question, as I read though the implementation, is "can the core
> benefits of this library be achived with a simpler 'light' version of this
> implementation?". While I appreciate the attempt to encode a Haskell-style
> typeclass hierarchy, I feel like that is not the core competency of hana
> and should be a separate library and discussion. As it is, this is a 32k
> header mega library. I'd prefer several small, highly-targeted,
> highly-composable libraries.
I agree that there is the Core of the library and the different types 
and algorithms.
I agree having highly composable types and algorithms, but why do you 
prefer them split in several libraries?
Is because having them on the same library allows the author to take 
some short cuts that shouldn't be used?
Is it because it would be difficult to add other libraries using the 
Core in a coherent way?
Is it because we need time to review each one of the Concepts, types and 
algorithms?
Or, ....
>
>>    * Implementation
>>
> The code itself looks to be well structured and well documented.
>
> Unfortunately hana only works with one compiler: clang. While I agree that
> Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is
> going too far in the opposite direction.
Why? we have discusses this a lot of time and it is up to the library 
author to state what compilers the library supports.
> The home page states that boost
> libraries "are intended to be widely useful, and usable across a broad
> spectrum of applications". I've always interpreted that statement to be in
> a practical rather than theoretical sense and I don't think hana meets that
> criteria.
The intent of the library is to be widely useful and it will be. Lets 
the time do his job.
> Many other Boost authors have made heroic efforts to meet that
> criteria and the reputation of Boost is due, in no small part, to those
> efforts.
You are right that some of us are spending a lot of time trying to cover 
multiple not conforming compilers and also multiple c++ versions. I 
believe that this is one of the things slowing the growth of Boost.
>
> I do appreciate the argument that making use of new features encourages
> compiler implementers to implement then. I maintain, however, that this
> isn't Boost's job. Boost provides high quality libraries that the every-day
> Joe C++ developer can benefit from.
Lets build them for the every-day Joe C++ developer of tomorrow. 
Stabilizing a library takes time. But we need that the library be used 
to learn more. Been in Boost would help to achieve it.
>
> That being my position on the issue, my acceptance vote is conditional on
> hana supporting at least two released versions of mainstream compilers.
> Given that gcc support seems pretty close, that shouldn't be hard to
> achieve.
>
I agree that at least two compilers seems a minimum.

Best,
Vicente