Proposal: Adding on

[Christian Maeder]

Since Data.Ord and Data.Eq now have there on modules and are part of the
prelude, I suggest to create Data.Function and put in "flip", "id",
"const" (did I forget one?) and "on". The prelude need/should not
reexport "on", though.

1. I agree to have comparing and equating separately (however implemented)

2. Data.Function seems right to me, too (because "Data.->" is illegal as
module identifier)

Christian


Duncan Coutts schrieb:
> 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).