Phobos orthogonality [Was: Re: quickSort]

[Jonathan M Davis]

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