Boost logo

Boost :

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:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at