Re: [boost] Hana Typeclass

Subject: Re: [boost] Hana Typeclass
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-03 17:50:14

Niall Douglas wrote
> On 3 Aug 2014 at 11:32, Robert Ramey wrote:
> 
>> To me the "type class" of the Hana library is a muddled re-implemenation
>> of
>> the boost concept check library.  Its much more complicated and subtle
>> and
>> not as well documented and doesn't add anything to BCC.
> 
> You probably didn't mean to Robert, but that review came across as 
> mean spirited. I'm going to assume you didn't mean it that way, 

I don't mean to be mean spirited and I haven't made any comments
referring to anything but the documentation and code.  The statement
above accurately summarizes my views after spending a couple of
hours looking at part of the documentation.  I realize that it's not
positive - but I honestly think that Louis is on the wrong track here
and I don't know how else to say this.  

> the same way you didn't mean it that way when you hassled Paul, also a 
> GSoC student by the way, in his C++ Now presentation about porting 
> AFIO to Boost.

well, I don't remember hassling anyone - at least on purpose.  The
only thing I remember about that presentation was mentioning that
I thought that porting a new library to work with C++03 was 
not necessary to be considered for inclusion into Boost.  I thought
was unfortunate that he spent this (considerable) effort and said
that had I known about it, I would have defended a decision not
to do it.  That's all I remember, so maybe I did hassle him.  If
so sorry about that.  If you want to pursue this, feel free tocreate a 
separate thread.

> Hana is different. This student engineer new to Boost and the way 
> things are done here has tried to break new ground and do new stuff 
> which demonstrates the power delivered by C++ 14 compilers. He's 
> taken a very Haskell-y route, right down to the un-C++ terminology 
> and not using STL idioms, but then so what if he has? 

I understand that.  But when I look at this I'm seeing 
a) re-invention of the wheel
b) and the new wheel compares unfavorably with the wheel we
already have.

> The STL is an ancient legacy design, it may be time to diverge
> drastically, or it 
> may not.

well, algebra is an ancient legacy design - but it's still quite useful.
STL has a number of rough edges - but it had a clear understandable
design so it will be around for quite a while.  Certainly, with C++xx
it might be possible to make something better, but we haven't seen 
it yet.  We've seen some hints though - ranges touch on upon this.

constexpr and the "melding" of compile time/runtime programming
will yield something interesting and I suspect that this is what
Louis is driving at.  But we haven't arrived anywhere yet.

> I have no idea if what he's done or how he's done it is the best 
> approach - I'm not competent in this area like Eric or Joel is. But 
> how he went about the prior art research, the benchmarking of all 
> implementation approaches, the presentation of his work at C++ Now 
> before proceeding with implementation, all of this bodes extremely 
> well indeed. Whatever he has done, it isn't going to be ill judged 
> and muddled, that's for sure.

I'm aware of this and don't dispute it.  This why  that's why I took
some time to make a good argument based sincere attempt to study 
things in depth as far as I could.  I've made a sincere criticism based
on references to specific quotes from the documentation and
examples.  If I'm missing something I'd be happy to hear about it.

> Hana isn't BCC. It's far more - 

I didn't say that hans is BCC. I said that hana type classes offer no more 
than BCC - I stand by that statement.

> it's potentially a hint of how C++ in 
> the 2020s could look like, which hopefully is not how things are 
> currently done right now. 

well, I've been flogging my ideas about how C++/Boost should look
in the future. (So far with very little success).  So I'm not
unsympathetic to changes - in fact I think they are necessary.

> I hope that the Boost culture is still able 
> to welcome radically new ideas and new engineers and stride forth 
> instead of this constant defence of the (ancient) past and its way of 
> doing things as if we're losing something vital other than our 
> membership, which if I can remind you, has been dropping for two 
> years now.

My view is that Boost needs to improve the quality of it's product.
Boost Libraries need:

a) better design
b) better conceptual integrity - easier to understand, better isolation
between interface and implementation.
c) better documentation - so far the only documentation approach which
has really worked well is that implemented for STL which "formally"
defines type constraints for generic algorithms.  We need to build on
that - not set it aside.
d) Easier tools to make and submit libraries.
e) more submissions
f) more and better peer reviews.

This is what drives me.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Hana-Typeclass-tp4665978p4665986.html
Sent from the Boost - Dev mailing list archive at Nabble.com.