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 itch to get D working in the OpenEmbedded environment...

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.

-- 
/Jacob Carlborg

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.