> It's not only about top-level functions named 'on'. If I use 'on' as a local variable, then I get warnings about local redefinitions of the global Prelude.on.

Oh heavens how did we not think of this point immediately? This frankly has me terrified of this proposal. This is such a cute name it's hard to imagine that it's not a local binding in numerous, invisible places.

(Just last week I had to fix a package not on Hackage because it locally defined (<>)...)

On Fri, Sep 13, 2019, 7:54 AM Henning Thielemann <lemming@henning-thielemann.de> wrote:

On Tue, 10 Sep 2019, David Feuer wrote:

> Every time I reach for Data.Function.on, I feel like a total dolt for having to import a module to get a function
> whose implementation is barely longer than the import. And it's a really good function too! Can we please add it
> to the Prelude?
>   on :: (b -> b -> c) -> (a -> b) -> a -> a -> c
>   (.*.) `on` f = \x y -> f x .*. f y

Most of the time I would use this I can use the more specific 'equating'
and 'comparing'.

I remember there was a lengthy discussion about the right name of 'on' and
adding it to Data.Function. I had no need for that function because at
this point I already had:
    https://hackage.haskell.org/package/utility-ht-0.0.14/docs/Data-Function-HT.html#v:compose2

If I am right the short name 'on' was only adopted because it was not
(automatically) exported by Prelude._______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries