digitalmars.D.learn - Another rambling musing by a Dynamic Programmer - map!
- John Carter (18/18) Jun 23 2014 So in Ruby and R and Scheme and... I have happily used map /
- Jacob Carlborg (6/23) Jun 24 2014 I wished Ruby behaved that way quite often, especially when chaning
- Ary Borenszweig (10/42) Jun 24 2014 My guess is that it's slower because it's implemented using fibers, so
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...
Jun 23 2014
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
Jun 24 2014
On 6/24/14, 4:13 PM, Jacob Carlborg wrote:On 2014-06-24 04:34, John Carter wrote: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.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.
Jun 24 2014