Proposal: add `on` to the Prelude

[Elliot Cameron]

> 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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190913/11bf8eb3/attachment.html>