On Tue, Jan 13, 2009 at 6:42 AM, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: > 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.
How about the loss of ability to inline the transformation function? I don't know if your current eager implementation can inline or not, but it could be a performance factor. But I would certainly like for you to be right about it being a free or very cheap lunch. >> 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. Another commonly used func from Python is zip(). Not sure if that one is doable in D because it relies heavily on Python's tuples to work, but in Python it offers a very clean solution to iterating over several lists at once. for xy in zip([1,2,3],[4,5,6]): # xy gets sequence of tuples (1,4), (2,5), (3,6) for x,y in zip([1,2,3],[4,5,6]): # tuple split into x and y automaticallly enumerate() is another one, enumerate(myarray) is basically zip(range(0,myarray.length), myarray). This eliminates the need for different overloads of opApply that differ only by whether or not they provide a counter. Also I really hope we'll be seeing lazy versions of the associative array properties .keys and .values! --bb