Re: [boost] Hana Typeclass

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 
http://lists.boost.org/boost-announce/2004/04/0041.php. Worth 
reading.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/