lazy thoughts

[Andrei Alexandrescu]

Bill Baxter wrote:
>>> 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

zip() is absolutely on the list.

> 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.

That's a great function too!

> Also I really hope we'll be seeing lazy versions of the associative
> array properties .keys and .values!

And that has been a thorn in a thorn-averse part of my anatomy for the 
longest time.


Andrei