Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-22 16:24:32

Bruno Dutra <brunocodutra <at> gmail.com> writes:

>
> [...]
>
> I would like to point out however, that from the point of view of someone
> who has basically solely done C++ his entire life, just like myself, Hana
> can look *very* unfamiliar. I understand it is mostly my fault for not
> properly having learnt FP before, however I believe I'm not alone among
> average C++ programmers, so I fear this could prevent many potential users
> from adopting Hana, simply because one tends to stick to things that look
> familiar to one.
>
> Now I'm not sure that is any easy way around this unfamiliarity. I've seen
> others pointing out that names could better reproduce the C++ standard
> library (to what I agree) and perhaps that's indeed all one could do to
> tighten the gap that separates Hana from mainstream C++ libraries. At any
> rate, I just felt I should stress this point, to make sure it is not
> underestimated.

I feel like a lot of the functionality provided by Hana can be used without
understanding advanced FP concepts. I'm referring (essentially) to the
contents of the cheat sheet at the beginning of the tutorial. These algorithms
are in essence just algorithms on tuples, and they are very similar to their
STL equivalents.

However, it is true that Hana is biased towards FP concepts, and for several
reasons. First, these concepts are very general and they give a lot of
flexibility. For example, I don't know many ways to define `filter` on an
Optional value, but it works when you go down the Monad road.

Secondly, organizing a lot of things around Functor (and the related FP
concepts) matches the compiler's execution model quite well. Indeed, this
allows expressing algorithms around the concept of "mapping a function over
a structure", which is efficient in the case of parameter packs.

Thirdly, heterogeneous programming prevents the use of a lot of mutation,
because most of the time you need to create a new object (with a different
type) to hold the result of an algorithm. Assigning this result to an
existing value wouldn't make sense, since you don't know the type of that
result beforehand. __Most of the time__.

Finally, there's my own personal bias. I wanted to dig deeper into category
theory and functional programming, which I did via this library.

>    - What is your evaluation of the implementation?
>
> I've just briefly peeked at the code base out of curiosity and it looks
> pretty clean and organized.
> The use of global function objects however intrigues me, why not free
> functions?

Function objects can be used in higher order algorithms, while overloaded
functions can't.

> I've also found myself stumbling on variable templates. Perhaps that's just
> me, but really I find they make everything so cryptic. Anyways, I guess it's
> not Hana's fault to make arguably good use of something that is part of the
> language.
>
>    - What is your evaluation of the documentation?
>
> I find myself blindly using the search button in hope to find whatever I'm
> looking for more often than I'd rather do, but perhaps it's just a matter
> of getting used to how the documentation is organized.

I think it's also a matter of reorganizing the documentation. The current
layout is great if you know the concepts by heart (great for me), but not so
great otherwise (so for everyone else).

This was raised a couple of times during the review and I'll try to improve
the situation, but that might mean switching away from Doxygen, which is not
a slim task.

> One thing I'd like to see improved is the alphabetical index. I'd expect it
> to be thorough, but at least "is_a" is missing, so I assume a rationale
> exists to decide what goes there? I think it would be better to list
> everything exhaustively, so users may rely on the browser's find tool to
> explore the library.

I guess that's because `is_a` is a variable template or something like that.
Frankly, instead of fixing this specific issue, I'll put energy on finding
a different documentation tool.

>    - What is your evaluation of the potential usefulness of the library?
>
> At first I was afraid Hana were too academical and abstract to be a good
> tool for getting down to business, but after playing with it a little bit I
> can see that, once one gets its design, it does make metaprogramming quite
> straightforward.
>
> I believe however that most users will attain to a very limited subset of
> functionalities in order to just get their tasks accomplished. So much so,
> that I'd strongly advise Hana to be split into one highly specialized tool
> for straightforward metaprogramming and another more abstract halve
> providing the more generic concepts. This could ease user experience
> considerably, reducing the novelty presented by Hana and thus tightening
> the gap I've mentioned before.

I think there is some desire from the community to have a very simple library
providing tuple algorithms, without concepts and anything else. I can
understand that, and I will see if Hana can be modularized in a way that
makes the core functionality usable without the rest of it.

However, I am under the impression that it would be better to simply create
a separate library. I'll make some experiments and time will tell.

>    - Did you try to use the library? With what compiler? Did you have any
>    problems?
>
> Yes on Clang 3.6.1.
> I tried to implement the unification algorithm [1] at compile time using
> Hana and, though I haven't actually finished, I could see it would
> be straightforward.
> In fact I gave up on it when I found a bug which prevented the construction
> of optional maps, but not too long after I contacted Louis and opened an
> issue [2] it seems to have already been fixed on develop branch. I didn't
> test the fix myself though.

The bug is now fixed on develop.

>    - How much effort did you put into your evaluation? A glance? A quick
>    reading? In-depth study?
>
> About 4 hours reading the documentation, another 4 hours trying the library
> and about 2 hours to write this review.
>
> *Bruno C. O. Dutra*

Thanks a lot for your review, Bruno. I'd also like to thank you for your
comments and questions on Hana prior to this review, and your challenging
opinions about the future of metaprogramming for C++.

Regards,
Louis