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
