Re: [boost] [Hana] Informal review request

Subject: Re: [boost] [Hana] Informal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-03-16 19:43:43

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/