Proposal #2659: Add sortOn and friends to Data.List

[Henning Thielemann]

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