Re: [boost] [Hana] Informal review request

Subject: Re: [boost] [Hana] Informal review request
From: Eric Niebler (eniebler_at_[hidden])
Date: 2015-03-16 23:27:04

On 3/16/2015 4:43 PM, Louis Dionne wrote:
<snip>
>    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.

I personally don't see a problem with keeping foldr's semantics but
changing the name to reverse_fold, if that's what people want.

> 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.

> [7] http://ldionne.github.io/2015/03/16/laziness-as-a-comonad

Awesome. I'm really looking forward to reading this.

> 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.

I'll be interested to see if/how you avoid Boost.MPL's lambda evaluation
semantics quagmire. I find the business of tracking whether/where
substitutions were done, conditionally probing for ::type, then
conditionally selecting the substitution, to be pretty unsatisfactory.
Too much magic, too difficult to grok, and could even cause errors by
causing inadvertent instantiations of things not meant to be
instantiated -- which means things need to be protect'ed, etc, etc. I
would prefer a simpler, more predictable algorithm, even at the expense
less pithy lambdas.

> 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.

Thanks for all your work, Louis.

-- 
Eric Niebler
Boost.org
http://www.boost.org