Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Eric Niebler (eniebler_at_[hidden])
Date: 2015-03-09 13:41:52

On 3/9/2015 9:38 AM, pfultz2 wrote:
>> I feel like Meta's approach to laziness hasn't been understood.
> 
> So in Meta, instead of sprinkling my code with `typename` and
> `::type`, I need to sprinkle it with `let` and `defer`. With Louis'
> approach to laziness, you wouldn't need either of these.

You use the algorithms in the meta::lazy namespace that are already
deferred, and only in the places where you need laziness. I find I only
need laziness in a few small places in my computation. The rest of the
time it obscures semantics. IMO.

Did you find the use of let/defer in my common_type example off-putting?
I find the solution elegant.

There's probably some bias toward laziness in metaprogramming here in
Boost due to the influence of the MPL. It's helpful to remember that in
the wider C++ community, computing a computation and /then/ evaluating
it is probably not the most intuitive thing. From my years on the Boost
list, I know that new users of the MPL are terribly confused about
if/when to access the nested ::type during a computation. (Arguably,
they would be similarly confused about when to use let/defer, but they
won't be confronted with that problem until they need laziness.)

Meta is aimed at people with light metaprogramming needs. It scales
well IMO, but the choice to put eager computation first is to make
simple things as simple as possible. It comes from the observation that,
when using Meta on real-world problems, I was almost exclusively using
the *_t aliases. So I flipped the interface around and found a different
way to express laziness.

Also, the nested ::type idiom feels like a hack around the lack of
template aliases in the language. Now that we have them, I thought it
would be interesting to try to build a MP library that assumes them.

There's room here for different metaprogramming libraries with different
approaches. I'm explaining Meta's approach because I felt it wasn't
understood, not criticizing anybody else's approach. I like Hana. I am
curious how it handles lambdas (does it have them?), and whether it
manages eagerness/laziness in lambdas in a more sane way than MPL.

P.S. I still would find it informative to see how my common_type example
looks in Hana and Turbo.

P.P.S. "l-e-t" is shorter than "t-y-p-e-n-a-m-e- -:-:-t-y-p-e" :-)

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