Boost logo

Boost :

Subject: Re: [boost] Hana Typeclass
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-03 18:27:49

On 4 Aug 2014 at 5:59, Joel de Guzman wrote:

> On 8/4/14, 4:42 AM, Niall Douglas wrote:
> > 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'd do it differently, if I were Louis. There was at least one library
> a few years ago (FC++) that attempted to get Haskell style into Boost.
> It was not accepted into Boost for many reasons such as the alien
> abstractions that somehow go against the grain of C++. This is C++,
> not Haskell. Another problematic point is the totally immutable design,
> again as an outcome of the Haskell lineage. It seems Louis likewise
> advertises Hana as immutable/const only. C++ folks embrace references
> and non-const operations as part of being C++. Perhaps Louis should
> study FC++'s Boost review and learn from it.

Firstly, I enormously appreciate your feedback here as you're one of
the established domain experts in this space. So thanks for that.

For those interested, FC++'s report is at Worth

I would add the following points to what you said, bearing in mind I
don't think myself competent in this domain:

1. From my limited understanding, FC++ had to make the compiler jump
around a lot, which made using it frustrating because it ended up
making the compiler create a ton of unnecessary output in order to
remain pure to use. Hana shouldn't have that problem.

2. I am not at all convinced that the STL idiom is appropriate for
compiler programming. With respect, Fusion and Phoenix I found
personally too brittle to use and too steep a learning curve to use
in any of my own code, plus I always struggled personally with why
some bit of design was the way it was and other bits were not (if you
searched as to why, the answer usually was language or compiler
limitations). A Haskell idiom is at least well understood and fully
thought through, and if it can be efficiently implemented by a C++ 14
compiler I would prefer to import a Haskell idiom than to create
something less fully baked and full of design inconsistencies which
steepen learning curves.

3. I personally found the immutability a huge positive in my
conceptualisation, and one I thought was a huge benefit over
Fusion/Phoenix for me. It lets the compiler fold away stuff much
easier, plus my brain likes to think in terms of forward progressions
of collapsing stuff into simple well understood chunks. I absolutely
admit this is probably an artefact of my lack of experience in this
domain, but for me at least as a next gen MPL++ that seemed right on
the money. MPL98 I have used in my own code after all, but anyone who
has used it gets the feeling it should be a lot better in some hard
to pin down kind of way.

> That being said, let me go for the record that I think Louis is
> doing a splendid job on Hana especially in the way he takes
> advantage of advanced C++14 facilities. If he can make it more
> C++-ish rather than Haskell-ish, then I think he'll be on the right
> track for acceptance.

I think he also needs to keep it small and tightly focused to stand a
chance - too many libraries are handed to Boost for review which
overlap others in a non-improving way. It may well be that when he
finishes the table of MPL98 to Hana equivalents the light bulb will
go on for everyone and the way forward becomes clear.


ned Productions Limited Consulting

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