On Tue, 7 Oct 2008, Wolfgang Jeltsch wrote:
Am Sonntag, 5. Oktober 2008 20:34 schrieb Duncan Coutts:
I think fewer names and more combinations is usually best unless there is a really compelling reason. Just because things are often used in combination doesn't mean we have to make a new name to represent that composition. As functional programmers we are very used to using composition, especially simple function application.
I fully agree!
The identifiers of the proposed new functions are rather systematic. So why not use the means of the language (combining higher-order functions) to express the underlying structure instead of relying on naming conventions and boilerplate code?
The problem is, that combinations of functions get larger and larger this way. I consider it good style to write short function definitions, which in turn use other functions, that make sense of their own. If every function definition is short, your argument would mean, that it is better not to define such functions at all, why not inlining all those definitions in the main program? Why having 'map' and 'filter', they are just 'foldr' with simple function arguments. I have once proposed to add 'toMaybe' to Data.Maybe [1]. It was rejected, because it can easily be implemented with 'guard'. However, that's not the point. It's often the case that 'toMaybe' is simpler to apply and it denotes a frequent pattern. So I continue to define it in the Utility modules of many of my packages. The same discussion arose about 'concatMap' and 'intercalate'. I see two extremes: 1. Minimal number of functions in standard modules and many re-implementations of common patterns in Utility modules of various packages or worse: large function definitions in application code. 2. Maximum number of functions in standard moudles for every combination or at least for every already used combination of functions, where application code only consists of calling one function from a standard module. I think none of the extremes is what we want. In my opinion if people become aware that a certain combination of functions is widely spread, or even more a certain combination is the main application of one of the invoked functions, this is a good sign to make this use pattern explicit by a new function. I share the impression with the original poster, that 'sortBy' and 'groupBy' are most oftenly used with 'on'. I remember that 'on' was precisely introduced to support 'sortBy' and 'groupBy'. However 'sortBy' with 'on' must recompute the sorting key. Such recomputation can only be avoided with a new function - or by optimizer rules, which replace 'sortBy (compare `on` f)' by 'sortOn f' and so on. [1] http://www.haskell.org/pipermail/haskell-cafe/2007-November/034259.html