lazy thoughts

[Bill Baxter]

On Tue, Jan 13, 2009 at 6:42 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at 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