Eric Niebler
[...]
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.
I think it might be nice. Something like auto f = hana::lambda< // similar to mpl lambdas, but better >; where `lambda` is a variable template creating a Hana Metafunction inline. I do think it could simplify some type-level programming; it's worth exploring. Thanks for the suggestion.
[...]
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.
I think so too, and it is on my (super long) todo list. Unfortunately, I'm only a man not an army. I'll try to have this in time for the formal review, which is aimed for April.
What are the benefits of eval_if over the if_ with lazy branches that you show at the bottom of [1]?
The if_ with lazy branches won't work if the condition is known at runtime and the branches have incompatible types. For example: eval(if_(true, lazy([x{1}] { return 0; }), lazy([x{"abcd"}] { return 0; }) )) is actually somewhat equivalent to auto branch = if_(true, lazy([x{1}] { return 0; }), lazy([x{"abcd"}] { return 0; }) ); eval(branch); However, since both lambdas have captures, their type is not compatible. Since the condition is not an IntegralConstant, it will fail inside the if_. Regards, Louis