Boost logo

Boost :

Subject: Re: [boost] [MPL] More lazy evaluation, for ease of use?
From: jcarey_at_[hidden]
Date: 2010-08-02 16:04:10

> On 8/2/2010 09:00 David Abrahams wrote:
> > On Jul 31, 2010, at 2:46 PM, Larry Evans wrote:
> > The mentioned
> > in that post is no longer there. Anybody have a copy they'd
> > care to post to vault so other's can have a look?
> Really wanting to close the vault--Anyone can get a GitHub account.
> Here's a link:

Thanks; Vesa Karvonen's LazyMPL library is exactly the kind of thing that I am looking for.

> On 7/31/2010 13:26 David Abrahams wrote:
> On Jul 30, 2010, at 6:48 PM, jcarey_at_[hidden] wrote:
> >
> > I think it would be helpful if all Sequences,
> > Iterators, and Lambda Expressions were also
> > nullary Metafunctions returning themselves.
> > (In particular, it would be nice if generic
> > containers designed for lazy data could
> > accommodate Lambda Expressions.)
> Not sure what you mean by that last part,

LazyMPL supplies some ready-made examples:

  // boost/lmp/pair.hpp:

  namespace boost { namespace lmp {
    template<class L>
    struct first {
      typedef typename first<typename L::eval>::eval eval;
    template<class H, class T>
    struct first<pair<H, T> > {
      // [***Note the "H::eval", which makes
      // "first<pair<H, T> >::eval" the same
      // C++ type as "H::eval". That way we
      // can use first<pair<H, T> > in place
      // of H in any lazy context. --John]
      typedef typename H::eval eval;

  // boost/lmp/op.hpp:

  namespace boost { namespace lmp {
    template<template<class> class F>
    struct op_1 {
      // [***Because op_1<F>::eval aliases op1_<F>,
      // "first<pair<op_1<F>, T> >::eval::template with"
      // works just like "F". Thus we can put functions
      // in lazy pairs without any special fuss. --John]
      typedef op_1 eval;

      template<class X0>
      struct with {
        typedef typename F<X0>::eval eval;

> but you might have a look at Vesa Karvonen's post:
> and the ensuing thread, oh, and the update. Actually,
> maybe is the best place to look.
[Omitting performance discussion and sieve example.]

Off hand I am not sure what the performance trouble
would be; it deserves a deeper look, and I wanted to
answer other points right away.

Meanwhile, let me just mention that the thread included
some questions about strictness analysis; and though it
is an oversimplification, I think a rule of thumb one
could start off with is: "Pre-evaluate an argument if
you know that it will be evaluated before return."

-- John

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