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
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  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 . 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 ?
> : http://ldionne.github.io/hana/structboost_1_1hana_1_1_lazy.html
-- Eric Niebler Boost.org http://www.boost.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk