lazy thoughts

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Tue, Jan 13, 2009 at 2:05 AM, Andrei Alexandrescu
 >> [snip]
>> Please let me know what you think!
> 
> I think having such functions is great.  I'm not so sure about
> removing the others and replacing them wholesale with these.  In
> Python they have had two versions of most functions, like range vs
> xrange.  The former returns an array with the result, the latter
> returns a lazy iterable.  In the Python 3.0 they have done away with
> most of the x__ versions and made those default.  So you might say
> A-ha! the array versions weren't necessary!  But the difference is
> that Python cares more about simplicity than performance, so a little
> loss in speed in exchange for only-one-way-to-do-it is acceptable
> there.

Here it's not as much about efficiency as about orthogonality. We know 
how to (lazy) map, we know how to force a computation, so why not allow 
people to mix and match them (as opposed to providing one-liners in the 
standard library).

> But I'm just guessing there will be some penalty for doing everything
> lazily in the case where you know you want a full array.  More data is
> needed on that I think.
> 
> But even assuming it's is a free lunch, I'd want a better way make an
> array than putting .eager on everything.  First off, that's not even
> remotely a verb (like .eval() or .exec()), nor is it a noun that
> clearly expresses the type it will become (ala array() or toArray()).

I believe (without having measured... which means that I am essentially 
lying) that we can safely assume the lunch will be free or low cost. The 
copying of the underlying range should be cheap except for the shortest 
ranges.

> Second it's just a lot of typing for something that could be a pretty
> common case, still.   I'd be happier with a one letter difference,
> like Python had.  But making the defaults the other way would be fine
> by me,   map -> lazy map   emap -> eager map.

Yah, I'll look into it. One thing is that not that many functions will 
end up being lazy. For example, reduce is eager (I think it's 
uninteresting to have it default to laziness). So will be sorting and 
searching functions. In fact map and filter are the poster children of 
lazy evaluation in today's std.algorithm. Of course there will be other 
lazy functions now that the door is open, such as Haskell's "take" etc.


Andrei