On 3/11/2015 8:00 AM, Louis Dionne wrote:
Eric Niebler
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