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.