Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Eric Niebler (eniebler_at_[hidden])
Date: 2015-03-11 19:41:49

On 3/11/2015 8:00 AM, Louis Dionne wrote:
> Eric Niebler <eniebler <at> boost.org> writes:
> 
>> [...]
>>
>> The identity function hack is a little unfortunate, but I understand the
>> need for it.
> 
> It is, but at the same time, when you start mastering it, it becomes 
> a powerful way of controlling exactly what should be deferred and what 
> shouldn't.
<snip>

Yes. Likewise for meta::defer.

>> What if the two branches return different types? [...]
> 
> Having both branches return objects of different types is definitely 
> possible. Actually, the whole thing was designed to make this possible.
> However, in order for the branches to be able to return unrelated 
> objects, i.e. ones without a common_type, the condition has to be 
> known at compile-time (e.g. an IntegralConstant).
<snip>

Naturally.

>> [...]
>>
>> Using lambdas for lazy conditionals brings limitations and pitfalls.
>> Would you consider adding a pure type-level alternative for people doing
>> straight metaprogramming?
> 
> I think that might be a good idea. More generally, It might be
> possible to provide a mini EDSL for lambda expressions that could
> look like Proto's transforms? I'm really just thinking out loud,
> but what do you think?

I wasn't thinking of a (runtime) EDSL like Proto. I was thinking of a
compile-time one like mpl::lambda. I know that's not the Hana way, but
Hana is bumping up against the limits of the language.

> For simple laziness, Hana also has a tool called `lazy`, which allows 
> creating function calls that can be evaluated later. For example:
> 
>     // nothing is evaluated nor instantiated at this point
>     auto lazy_result = lazy(f)(x1, x2, x3); 
> 
>     // everything happens now
>     auto result = eval(lazy_result);

This is *exactly* the runtime equivalent of meta::defer. And the example
at the bottom of [1] is exactly like my "test_lazy_if_" example a few
posts back. Needless to say, I like this approach to laziness. It is
simple and intuitive (to me). :-)

> Lazy is a Monad, which allows chaining lazy computations as shown 
> in [1]. However, Lazy is not integrated with eval_if right now, which 
> makes it pretty much useless. The reason why it is not integrated is 
> because I think it can also be made a Comonad, and I wanted to see how 
> lazy branching might be generalizable to arbitrary Comonads. 
> I haven't had the time to explore this further for now though.

FWIW, I think this is important. What are the benefits of eval_if over
the if_ with lazy branches that you show at the bottom of [1]?

> [1]: http://ldionne.github.io/hana/structboost_1_1hana_1_1_lazy.html

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