Re: [boost] [MPL] More lazy evaluation, for ease of use?

On 8/2/2010 09:00 David Abrahams wrote:
On Jul 31, 2010, at 2:46 PM, Larry Evans wrote: The http://groups.yahoo.com/group/boost/files/LazyMPL/ 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: http://github.com/dabrahams/mpl0x/downloads
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@jcarey.best.vwh.net 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: http://lists.boost.org/Archives/boost/2004/10/74984.php and the ensuing thread, oh, and the update. Actually, maybe http://tinyurl.com/lazympl 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
participants (1)
-
jcarey@jcarey.best.vwh.net