On Wednesday, September 14, 2011 07:46:37 bearophile wrote: > Jonathan M Davis: > > What would that gain you over passing the result of map or filter to > > std.array.array? > > 1) The code gets shorter > 2) The code gets a bit less noisy, because () add noise. > 3) You use a single function instead of two, so you reduce the number of > chunks your brain has to manage. A human brain is able to manage a very > limited number of chunks at the same time (about 7). An expert programmer > is able to merge array(map()) into a single chunk, but this requires a bit > of training and time. 4) Maybe you are able to reduce the abstraction > penalty for the compiler, reducing the amount of code compiled. (But this > probably will not happen because amap will probably be just implemented > with an array(map()) to reduce library code and time to write to write it). > 5) The lazy result of map is quite useful. But in a large amount of > situations in D you can't use a lazy result, you need an array (this is not > true in Haskell). So in practice about half the time I need a map, I have > to apply array() on it. So amap is a very common pattern in D. 6) In > std.parallelism there is already an map/amap pair: > http://www.d-programming-language.org/phobos/std_parallelism.html#amap > So for the D programmer it's not a significant burden to have the same > functions in std.algorithm, with the same names and same purposes. > > Orthogonality is overrated in Phobos. If you take a look at functional > languages where the use of higher order functions is common, like Haskell, > you see standard functions that are the composition of common functions. > Haskell designers have a large experience on the usage of higher order > functions. This is the Haskell Prelude (similar to the D object module): > > http://www.haskell.org/onlinereport/standard-prelude.html > > As example it contains both map and concatMap (concatMap is absent in Phobos > still, but it will be useful to have). > > The definition of concatMap is just: > > concatMap :: (a -> [b]) -> [a] -> [b] > concatMap f = concat . map f > > In practice in Haskell you are allowed to write concatMap just like this: > > concatMap = concat.map > > This means concatMap is just using three functions, concat, map and dot > (that is the composition function). Do you know why such simple function is > included in the Prelude, despite it essentially saves just one character > (the dot)? Because using a concat on the result of map is a very common > pattern in Haskell code. So packing them in a single name allows the mind > of the programmer to think of it as a single entity, and allows a bit > higher thinking while you program. > > This is why I think amap/afilter are worth adding to Phobos. I did have them > in my dlibs1 and I have used them many times.
So, basically, you just want to shorten your code by wrapping array(func) in a afunc function, and you think that this happens enough with map and filter enough to merit putting these functions into Phobos. Yeah, I don't see that happening. It's not impossible, but there are a number of functions in Phobos which return lazy ranges. It's not at all reasonable to have duplicate versions of them all just to shorten a bit of code. And if anything, Andrei has been looking at heightening the bar for how much a function has to add to make it into std.algorithm or std.range. He feels that there's arguably too much duplication already. And when all a function does is making so that you're doing afunc(r) instead of array(func(r)), there's no way that that's getting in. - Jonathan M Davis