Proposal: Adding on

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Nov 2 17:21:13 EST 2006


I agree it should go in.

I wonder about how this relates to 'comparing' which we already have in
Data.Ord. Does adding 'on' mean we should remove 'comparing' ?

I would suggest we keep both and add 'equating' to Data.Eq too, for
symmetry with 'comparing'.

Why? Because for the cases covered by comparing/equating I think the
code feel simpler and reads more naturally.

In my own code I think I would use comparing/equating when using the
ordinary Ord/Eq instances and use `on` when I was using a non-standard
comparison.

Duncan

On Thu, 2006-11-02 at 18:00 +0100, Nils Anders Danielsson wrote:
> The function on defined by
> 
> (*) `on` f = \x y -> f x * f y
> 
> is convenient when using functions like sortBy: sortBy (compare `on`
> fst), for example. It also makes the code more readable.
> 
> Furthermore I consider on to be above the Fairbairn threshold, since
> * we get rid of two lambdas,
> * we get rid of the duplication of p,
> * on has some nice algebraic properties (documented in the patch)
> * and, most importantly, it is easier at a glance to understand
>   (*) `on` p than to understand \x y -> p x * p y (assuming one knows
>   about on).



More information about the Libraries mailing list