lazy thoughts

Max Samukha samukha at voliacable.com.removethis
Mon Jan 12 11:37:36 PST 2009


On Mon, 12 Jan 2009 09:05:18 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:

>(I originally emailed this to Walter and a couple others, but I thought 
>it might be better to gather insights from the community.)
>
>I'm gearing up for changing std.algorithm, and I am thinking of making 
>the major change of favoring lazy evaluation throughout. For example, 
>consider the map function. Right now map allocates and returns a new 
>vector, for example:
>
>int[] arr = [ 1, 2, 3, 4 ];
>auto squares = map!("a * a")(arr);
>assert(squares == [ 1, 4, 9, 16 ]);
>
>What happens is unfortunate because (1) all evaluation is done upfront 
>even if it is only partially needed, (2) allocation is done every call, 
>(3) the whole scheme won't work with unbounded inputs, e.g. generators 
>or even large files.
>
>So now that we have nice range support in the language, I'm thinking 
>very seriously of switching full-bore to lazy semantics. In that case 
>map returns a range - a little struct that saves the input and trickles 
>out results one at a time.
>
>One nice thing about lazy is that lazy includes eager. If you actually 
>want to "eagerize" map, you just call eager against the returned range:
>
>int[] arr = [ 1, 2, 3, 4 ];
>auto squares = eager(map!("a * a")(arr));
>assert(squares == [ 1, 4, 9, 16 ]);
>
>The real advantage comes when you actually exploit the laziness, e.g.:
>
>int[] arr = [ 1, 2, 3, 4 ];
>auto squares = map!("a * a")(arr);
>foreach (x; squares) {
>     writeln(x);
>}
>
>Look ma, no allocation!
>
>I just wanted to gauge your opinion on this. It is a major departure 
>from the STL, and I think in the right direction. It is a departure 
>nonetheless and some STL users might feel uncomfortable.
>
>Also, lazy evaluation has the risk of getting confusing as there's a lot 
>of escaping. Consider:
>
>int[] arr = [ 1, 2, 3, 4 ];
>auto squares = map!("a * a")(arr);
>arr[] = [ 5, 6, 7, 8 ];
>
>Now iterating squares will see different numbers than the original ones.
>
>Please let me know what you think!
>
>
>Andrei

That's just great. If the ranges design is settled, could you please
release an updated RFC?



More information about the Digitalmars-d mailing list