Proposal #2659: Add sortOn and friends to Data.List
lemming at henning-thielemann.de
Fri Oct 10 04:54:52 EDT 2008
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 . 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
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.
More information about the Libraries