Re: [boost] [Hana] Formal review

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

Le 18/06/15 05:59, David Sankel a écrit :
> On Wed, Jun 17, 2015 at 3:29 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
> 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:
>>>
>>>   You are strongly encouraged to also provide additional information:
>>>> - What is your evaluation of the library's:
>>>>     * Design
>>>>
>>>>
>>> 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?
>>
> Thanks for the great question Vincente.
>
>
>> Is it because we need time to review each one of the Concepts, types and
>> algorithms?
>>
> That's a bit of a strawman, but yes I'd like to review core hanna (which is
> mostly what is used in the examples) and then review major libraries built
> on hanna (such as the Haskell typeclass stack that is currently included).
>
> My main interest in a simpler release is that we'll get more people
> attempting alternative strategies for, say, doing a applicative/monad/etc.
> stack built on hana. That experience and competition will be better for the
> C++ communities we serve.
>
> My secondary interest in a smaller release is related to the flip-side of
> Parkison's law of triviality. Perhaps it should be called reactor-building?
> hana is very large and I think there are few who are going to do all its
> subcomponents justice in a review. I know I'm not.
>
I agree that I have not taken the time to review every concept and 
algorithm. And I don't share the design of some of them.
The question is, if having them in Boost.Hana prevents others to propose 
their own stack of Haskel like type classes?

We have not discussed too much about the way the mapping of a type to a 
concept is done currently. I preferred the old way making the mapping of 
all the operation all at once.

I believe that there will a problem in identifying where the Core of 
Hana is? David, Louis, do you have a clear idea of what could be this 
Hana/Core?
>>>      * 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.
>>
> Given your comment below ("I agree that at least two compilers seems a
> minimum.") it seems that we agree a line needs to be drawn and where it
> should be drawn in this particular instance.
>
> While it is up to the library author which compilers to support, it is up
> to us reviewers to decide if their proposed choices are acceptable.
I would say it is up to the review manager ;-)
>
>   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.
>>
> The boost home page does not state that boost libraries "are intended
> to *eventually
> *be widely useful, and usable across a broad spectrum of applications".
> It's a subtle, but big difference. One sentence is attractive to the
> majority of companies who make real software, and the other is not.
>
> C++, more or less, is a language for engineers who make multi-platform,
> large-scale, high-performance, long-lived applications and libraries. I
> like that Boost has been a library collection for these folks and hope it
> stays that way.
What is wrong having Boost libraries that some companies can not use 
because they not work with the compilers they use?
I find that it is a good thing if there is at least one that can use it. 
And Boost is not only for companies. There are a lot of people that has 
more freedom on the choice of the compiler version they use than a 
company can have that would profit in having Hana in Boost.
>
>   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 think you must not mean growth in adoption because wide compatibility is
> one of the biggest arguments in favor of adopting boost in a company. What
> kind of growth do you mean?
>
I mean grow in more useful libraries. Each company has its own criteria 
about which 3pp libraries can be used. Portability is one of them but 
not the only one. and as I said there is more than companies on the world.
>>> 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.
>>
> I agree that a library being in boost will imply more usage. People use new
> libraries in Boost in a large part because they trust in the quality of
> libraries in boost. That reputation was earned, in turn, because quality
> libraries [from an engineering perspective] have wide compatibility. hana,
> with one supported compiler, isn't there yet.
>
>
Are you suggesting to postpone the inclusion of Hana for 3-6 months?
I will not be against freezing the inclusion of Hana in a Boost release 
until there are at least two supported compilers. It could however be 
included on the develop branch in order to be ready to be include this 
day ;-)

Vicente