Dear Boost, Here is a non-exhaustive list of some issues that were raised during the informal review of Hana last week, along with an explanation of what I did or am doing to resolve them. 1. It was suggested that size be renamed to length. The resolution is that an alias to `length` named `size` was added. `length` was kept because it applies to any Foldable, which includes things like Maybe. I found that writing `size(just('x'))` or `size(nothing)` made less sense than writing `length(just('x'))` or `length(nothing)`. Also, I find it prettier. This resolution should satisfy those seeking consistency with the standard library, while causing a minimal amount of changes to Hana. 2. It was suggested that `assert` be used in the documentation instead of other Hana specific macros in order to simplify things. The resolution is that I use `assert` and `static_assert` at the very beginning of the tutorial, and I then briefly explain what are those other macros. I then use those Hana-specific macros in the documentation because they provide more information to the reader than `assert`/`static_assert`. 3. It was suggested that the `algorithm`/`algorithm_if` convention be used for algorithms accepting an optional predicate. The resolution is that this convention is now used whenever it makes sense. In particular, the following algorithms were added/renamed: - count(seq, pred) -> count_if(seq, pred) + count(seq, val) - adjust(seq, pred, f) -> adjust_if(seq, pred, f) + adjust(seq, val, f) - replace(seq, pred, val) -> replace_if(seq, pred, newval) + replace(seq, oldval, newval) - find(seq, pred) -> find_if(seq, pred) - lookup(seq, val) -> find(seq, val) 4. It was suggested that `foldl` and `foldr` be renamed to something else. I started a poll at [1] to ask for the people's opinion, and the results so far clearly show that people want `fold/reverse_fold`. There is currently no resolution because I realized afterwards that `reverse_fold` in Fusion and `foldr` in Hana do not have exactly the same semantics. First, the order of the arguments is flipped, i.e. reverse_fold(seq, state, f) == foldr(seq, state, flip(f)) This is a benign difference. However, there is a more serious incompatibility stemming from how `reverse_fold` is usually specified and understood: as starting from the end. This causes a problem for infinite data structures, which obviously have no reachable end. Instead, `foldr` is usually specified recursively in a way that makes it possible to right-fold infinite data structures (and it is indeed possible to do so in Haskell and with MPL11). There is no real support for infinite data structures in Hana right now, but simple Concept generalizations which I have been thinking about might make this possible. In summary, I want to make sure I'm not blocking myself if I make the `foldl/foldr` change, but rest assured that I understood very well the people's desire. 5. It was suggested that some errors should be caught at the interface level, like when one uses a function with arguments that do not model the proper concepts. The resolution is that almost all the algorithms now static_assert that their arguments are models of the proper concepts (when possible). These checks can be enabled or disabled with the BOOST_HANA_CONFIG_DISABLE_DATA_TYPE_CHECKS macro, which is documented at [2]. 6. In a different thread [3], it was suggested that a MPL-like interface for type-only computations be provided. I implemented part of the MPL in a somewhat-backward-compatible manner, as can be seen at [4]. I am pondering whether to include it as part of Hana's public interface or to leave it as a proof of concept in the example/ directory. So far, I have not witnessed any use case in which type-only computations expressed in a classic MPL style provide a substantial gain over type-level computations expressed in idiomatic Hana, and actually I found it to often be the contrary. I'm waiting for a good reason of pushing that idea forward before I do it. There's also a poll at [5] if you want to express yourself. 7. In a different thread [6], it was suggested that the Logical concept should interact well with Lazy computations. I have begun to investigate possible ways of nicely tying both together, as can be seen at [7], and will try to have something definitive before a formal review. 8. In the same thread [6], it was also suggested that Hana provides a way to write inline metafunctions, pretty much like MPL's lambda expressions. I think this is an interesting idea that could make simple type-level computations super easy to write and I will try to explore it in time for the formal review. If you think I am missing something above, and that an issue was raised but not acknowledged or addressed, please reply to this message and I will make it right. Also, if you have more comments, please keep them coming. In the interest of full disclosure, the plan is to ask for a formal review during the month of April and then present the results of the review at C++Now in May. To put all the chances on my side, I would like to rule out as many objections as possible before we even start the review, so please raise your objections as soon as possible so I can address them. Regards, Louis [1]: https://github.com/ldionne/hana/issues/18 [2]: http://ldionne.github.io/hana/group__group-config.html [3]: http://article.gmane.org/gmane.comp.lib.boost.devel/257894 [4]: http://goo.gl/59xTvj [5]: https://github.com/ldionne/hana/issues/19 [6]: http://article.gmane.org/gmane.comp.lib.boost.devel/258248 [7]: http://ldionne.github.io/2015/03/16/laziness-as-a-comonad/