Boost logo

Boost :

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

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


>> [...]
>> 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]:

Eric Niebler

Boost list run by bdawes at, gregod at, cpdaniel at, john at