Another rambling musing by a Dynamic Programmer - map!

[Ary Borenszweig via Digitalmars-d-learn]

On 6/24/14, 4:13 PM, Jacob Carlborg wrote:
> On 2014-06-24 04:34, John Carter wrote:
>> So in Ruby and R and Scheme and... I have happily used map / collect for
>> years and years.
>>
>> Lovely thing.
>>
>> So I did the dumb obvious of
>>
>>     string[] stringList = map!...;
>>
>> And D barfed, wrong type, some evil voldemort thing again.
>>
>> So..
>>
>>     auto stringList = map!....;
>>
>> and we're good..
>>
>> and happily use it as
>>     foreach( s; stringList)....
>>
>> Suddenly the words in the map! documentation made sense to me... unlike
>> Ruby, map doesn't allocate and populate an array. It just returns a lazy
>> range.
>>
>> No array is allocated (unless I ask for one), it just does the lambda
>> when I want it in the foreach!
>>
>> Cool! Very very cunning. Very light on resources.
>
> I wished Ruby behaved that way quite often, especially when chaning
> multiple functions. In Ruby 2.0 there are lazy "map" and similar
> functions but I've heard they are slower than the eager ones.

My guess is that it's slower because it's implemented using fibers, so 
you loose a lot of time creating the fiber and switching contexts. But 
in this way any Enumerable can be turned into a lazy one.

I think they could optimize it for arrays by, for example, making a 
specific Enumerator without the need to use fibers.

In fact, I tried this in Crystal and I got performance similar to that 
of D. So you get the best of both worlds: you can either choose to 
always return an array, or to lazily apply transformations to it. I find 
returning an array to be more intuitive and easier to reason about.