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/